Opengl will be slower than sdl on computers with either bad graphics cards
or bad graphics drivers, but in general it is much much faster.  On the
order of 10 times faster or more for some things.  But you have to code the
opengl way, and not the sdl way.

Directly modifying pixels in a texture is going to be slower than blitting
pixels to the screen, so you will want to use another interface to draw
pixels to a texture and then replace the texture for it to be update on the
screen.  If you can find a way to accomplish what you want without changing
or editing textures, it will probably work a bit better.  On more advanced
cards you can use pixel rendering functions to offset this issue, but that
is less portable.

Another common slowdown with using opengl for 2d is badly sized textures.
Most cards will either have graphical errors or run slowly if any texture is
not a power of 2 in size (256x256, 512x512 etc).  This is not much of a
problem, since you can use scaling of polygons rather than scaling of a
textures pixels in order to make anything look the right size on screen.

Finally, polygon count does matter.  If you use tiles and make a giant map,
say, 10,000 x 10,000, and then blit that whole map to the screen, it will
run incredibly slow.  You have to be just as careful in opengl on how much
data you pass to the renderer as you would have to watch the number and size
of your blits in sdl.

Lastly, display lists or other batch techniques to limit the amount of
functions python has to call are a must.  Python function calls are slow, so
if you are telling opengl to draw each vertex of the entire scene every
frame, it could possibly be slower than the blits would just due to the
python overhead.

I'd like to see what your test was that ran slower in opengl than sdl.
Everything I've done has ran 100-300 fps in opengl versus 40-60fps being
about the max  I've EVER seen SDL run anything.

Reply via email to