Re: [PyOpenGL-Users] 2d sprite engine performance.

[Mike C. F. <mcf...@ro...>]

Erik Johnson wrote:
...

>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.
>  
>
Btw, IIRC, performance for graphics chips of that age (Rage 128 (which I
*think* is around the age of a TNT)) was to max out around 1000 to 1500
textured, lit polygons/second (games use (fairly advanced) culling
algorithms to reduce the number of polygons on-screen for any given
rendering pass).  Eliminating lighting should increase that to around 2
or 3000 polys, but that was with the old (small) textures that were
heavily reduced (32x32 or 64x64).

I wouldn't be surprised if you're running into texture bandwidth
problems and maybe even simple fill-rate problems.  You may find that
the card is extremely sensitive to colour mode for its performance (IIRC
switching a TNT to 16-bit mode would get close to doubling frame-rates
on our VR system of the time).

>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.
>  
>
Just to be clear:

    * You *are* running those glBegin...glEnd blocks as display-lists,
      not immediate-mode calls, right?
          o You create a display list holding each sprite to draw (you
            may only need one, depends on the proportions of the sprites)
          o Sort the sprites by texture (and by potential overlap
            (virtual Z ordering))
          o Load the texture
          o for (x,y,z),sprite in textureset:
                + glTranslated( x,y,z )
                + glCallList( sprite )
    * If your sprites don't actually move much you could put the
      glTranslate calls into the lists and then use glCallLists instead
      (assumes, however, that you don't have overlap)

Python is much slower than equivalent C; to get decent performance you
do need to use a mechanism that pushes the code down into C.  I normally
use array geometry myself, but then I normally do 3D work with game-like
rendering loads.

>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. 
>  
>
Display lists likely would help if you're currently drawing the polygons
with run-time calls: create a single "sprite" display list for your
standard sprite size, call that once for each sprite (after translate
and texture load) to do the
glBegin();glVertex(...);glTexCoord(...);glVertex(...);glTexCoord(...);glVertex(...);glTexCoord(...);glVertex(...);glTexCoord(...);glEnd(...)
and you've just reduced the number of Python calls by a factor of ~10. 
That *should* have a significant effect on performance.

>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.
>  
>
Sounds like a lot of extra bitmap bandwidth (re-storing the
background).  You likely do *not* want to be doing Vertex calls directly
from Python save to generate a display list (as noted above).  Python
just isn't the right tool for that kind of low-level operation, it has
too much per-call overhead.  If you do that kind of thing you should be
using array geometry (and be sure you use exactly the correct array type
for the data-type of the calls you're making to avoid extra copying).

>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?
>  
>
Python is slower than C, but OpenGL has an enormous amount of room to
play.  Using higher-level features from the higher-level language can
make the experience much more rewarding.

HTH,
Mike

________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com