The test was essentially fill with background color and add a fps counter.
On 7/8/07, Ian Mallett <[EMAIL PROTECTED]> wrote:
Hmmm. Well, you seem to be right. I ran the test and OpenGL was faster. I'm guessing it's my graphics card (I got a new laptop). On 7/8/07, Patrick Mullen <[EMAIL PROTECTED]> wrote: > > 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. >
