[PyOpenGL-Users] 2d sprite engine performance.

[Erik J. <ejo...@fa...>]

For a few months I have been doing hobby work on a 2d tile based game
using PyOpenGL.  I find that I am running into performance limitations
on older hardware, and I hope that the list might have some advice.

First let me explain what I am working with.  The code runs strictly in
ortho mode, and doesn't use lighting or the depth buffer.  All the
graphics work is done with individual texture mapped quads used as
sprites.  All the sprites have an alpha channel.  Some of the sprites
are rotated.

I have set up an experiment using my game engine to draw unmoving
sprites in a window and do nothing else.  On my 500mhz G3 iMac with a 
Rage128 Ultra, I can draw about 250 items before the frame rate starts 
dropping below 30fps.  Is this a reasonable number?  It seems low to me.
Can this class of hardware only handle 250 textured quads in a frame?
Is it unreasonable to expect more?

Let me explain what I have discovered on my quest for better
performance.

The profiler indicates that most of the program time is spent in my draw
function.  Adjusting the number of draw calls I make supports this
conclusion.  But Apple's OpenGL profiler tells me that only 10% of the
app time is spent in OpenGL.  I think the Apple tool is lying to me.

The engine seems to be CPU bound not GPU bound.  An 900mhz cpu with a
Geforce 3 runs the game much slower than a 1400mhz cpu with an
integrated S3 graphics chipset.

Eliminating texture switches by grouping my textures onto a single large
texture has helped noticeably.

Vertex arrays run slower than immediate mode.  Because the sprites can
move every frame, the vertex array changes every frame.  In my case
generating the array and calling glDrawArrays is slower than many 
glBegin ... glEnd blocks.

I think part of my problem is that I want to draw many quads that are
constantly moving relative to each other.  OpenGL performance tips I
have found are targeted at groups of polys that are relatively static. 
Display lists and vertex arrays don't seem to fit with my sprite 
approach. 

The other optimizations that I can think to try now are cutting out as
many glBegins and glEnds as possible, and do big groups of Vertex calls.
Or I can try rendering any sprite that won't move for a few frames to 
the background, and work around the problem by cutting down on the
number of sprites I have on screen.

I would love to hear opinions.  Is Python just slow?  Should I just give 
up on older hardware?  Does it sound like I am doing something wrong?  
Are there other optimizations that people can suggest?

Thanks!

Erik