[SDL] Techniques for dirty-updates (converting from 2D SDL to OpenGL)
david at olofson.net
Fri Nov 21 03:22:00 PST 2003
On Tuesday 18 November 2003 21.29, Stephen Anthony wrote:
> I've recently ported an SDL 2D emulator to use OpenGL. I have a
> texture sized at 512x256, and use glTexSubImage2D to update the
> approx. 320x200 framebuffer at 60 fps.
> When using SDL, I used SDL_FillRect() on dirty areas of the screen.
> This resulted in a maximum CPU usage of 4-5%, which is quite
> respectable (this is for the whole emulator, sound included).
> Now when using OpenGL, the usage has risen to 12-13%. I've
> narrowed the increase down to the glTexSubImage2D() command. While
> I still fill the SDL_Surface using a dirty-update scheme, I send
> the *whole* thing with glTexSubImage2D(). I'm wondering if it
> would be more efficient to have multiple calls to
It *should* be, since the actual transfer is the expensive part, but I
wouldn't bet on all drivers getting it right. Either way, try to keep
the number of rects reasonable (whatever that is), since there will
always be some overhead. Maybe provide a "simple update" option so
users can try that if they're having performance issues.
> I'd appreciate advice, web sites, etc, on how to do efficient 2D
> graphics in a 3D environment. Specifically, if I have an SDL
> surface that uses dirty-updates and is filled with SDL_FillRect,
> what is the fastest equivalent in OpenGL.
That depends on how the rendering is done.
Machines like the Atari ST and some 8 bit machines that lack sprites
and (ab)usable text modes are problematic as the games usually do
most rendering in software. You may not even be able to use dirty
rects without significant overhead. (You'd have to trap all VRAM
accesses the emulated CPU does, or do some brute force test on the
frame buffer after each frame.)
If you're emulating a character generator + sprite based display, try
dropping the software rendering and doing it all in OpenGL.
Characters and sprites would be textures and normal rendering would
be done using "pure" OpenGL. The textures would become procedural
only if the emulated game/application keeps messing with the graphics
Note that hardware scrolling of "true" graphic planes can be
implemented in pretty much the same way as on the real hardware. Make
the textures correspond to the VRAM; not the display. That way, you
can have the 3D accelerator emulate the plane + sprite combining
hardware, instead of emulating the whole thing pixel by pixel in
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
More information about the SDL