[SDL] Techniques for dirty-updates (converting from 2D SDL to OpenGL)

[David Olofson]

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
> glTexSubImage2D().

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 
data.

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 
software.


//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 ---