[SDL] Question about RLEACCEL-Bug

[David Olofson]

On Sunday 01 July 2007, Tim Schürmann wrote:
[...]
> > When you need to do pixel operations on
> > surfaces, don't use RLEACCEL.
> 
> In my game, I need the colour-value from several pixels. So I
> perform only reading-operations. Should I avoid 
> RLEACCEL in this case too? (The game reacts now as it should :)).

Depends... RLE might speed things up a lot in some cases, and then you 
don't want to disable it, obviously. OTOH, having SDL decode and 
re-encode the RLE when locking and unlocking is rather expensive, so 
the net result could be slower than not using RLE in the first place.

If you only need to *read* pixels from the surface, you might get away 
with blitting from the surface to a "scratchpad" surface, and read 
from there. Even doing that for the full surface should be faster 
than lock/unlock with RLE, as you avoid the re-encode step - and if 
you can get away with reading only a few small rectangles, it should 
be pretty fast.

Another trick is to keep a shadow surface; a plain, non-RLE copy of 
the "real", RLE encoded surface. Use the RLE accelerated surface for 
blitting, and the RGB shadow for reading.

If you're doing pixel accurate collission detection, the standard 
solution is pretty much the same as the shadow surface version, 
except you use a bit map instead (one bit per pixel), to save some 
memory and/or speed things up a little further.


//David Olofson - Programmer, Composer, Open Source Advocate

.-------  http://olofson.net - Games, SDL examples  -------.
|        http://zeespace.net - 2.5D rendering engine       |
|       http://audiality.org - Music/audio engine          |
|     http://eel.olofson.net - Real time scripting         |
'--  http://www.reologica.se - Rheology instrumentation  --'