Improving SDL'c RLE handling

Hi,

I have a small proposal for the way SDL handles RLE optimized surfaces.
The way SDL blittes RLE sprites that are partly clipped is not fully
optimized yet.

When SDL copies sprites which are partly above the screen then SDL
currently needs to parse the Sprite data to find the first visible row.
Example: When we have a sprite of 100x100 pixel of which only the last
10 rows are on the screen, then SDL still has still to read all 10,000
pixel to find the visible 1,000 pixel.

My proposal is to not use the current magic (0,0) words to mark a
beginning a RLE row but instead to use a list of length-words (type
uint32) which point to the beginning of each row in the sprite data.
So a clipped sprite would only need to fetch one long to know where the
sprite data of the first visible row starts. This will speed up top
screen clipped sprites noticeable. A sprite will only take the time for
blitting the visible content and not need to read the whole sprite like
before.

I hope you will find this idea usefull.

Cheers
Gunnar

I have a small proposal for the way SDL handles RLE optimized surfaces.
The way SDL blittes RLE sprites that are partly clipped is not fully
optimized yet.

When SDL copies sprites which are partly above the screen then SDL
currently needs to parse the Sprite data to find the first visible row.
Example: When we have a sprite of 100x100 pixel of which only the last
10 rows are on the screen, then SDL still has still to read all 10,000
pixel to find the visible 1,000 pixel.

My proposal is to not use the current magic (0,0) words to mark a
beginning a RLE row but instead to use a list of length-words (type
uint32) which point to the beginning of each row in the sprite data.
So a clipped sprite would only need to fetch one long to know where the
sprite data of the first visible row starts. This will speed up top
screen clipped sprites noticeable. A sprite will only take the time for
blitting the visible content and not need to read the whole sprite like
before.

Not a bad idea. Would you like to submit a patch relative to current CVS?

Thanks!
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

Dear Sam,

Sam Lantinga wrote:

I have a small proposal for the way SDL handles RLE optimized surfaces.
The way SDL blittes RLE sprites that are partly clipped is not fully
optimized yet.
[…]
Not a bad idea. Would you like to submit a patch relative to current CVS?

Yes, I will.

I have one question regarding the handling of RLE surfaces.
I only had a brief look at the SDL source but so far my understanding
is that each surface can buffer for one RLE compressed image.

My (simple) approach on handling sprites was by having ONE surface
containing all the sprites of my application. (See attached example).
My app was blitting the appropriate sprite out of the big surface.
While this works well with uncompressed sprites this is suboptimal for
RLE compressed data IMHO.

What is the recommanded way of handling this?
Is the only way of handling this creating
one surfaces one for each single sprite frame?

Cheers
Gunnar

As of now, yes.

With the change you’re suggesting, one could tile sprites vertically
without additional cost, but I’m not sure there’s any point in normal
applications. If you have very large numbers of small sprites, the
lower memory overhead and reduced cache load might make it worth
trying. Benchmark and see what happens with your particular
application.

//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 --'On Tuesday 18 April 2006 12:24, Gunnar von Boehn wrote:

Dear Sam,

Sam Lantinga wrote:

I have a small proposal for the way SDL handles RLE optimized
surfaces.
The way SDL blittes RLE sprites that are partly clipped is not
fully
optimized yet.
[…]
Not a bad idea. Would you like to submit a patch relative to
current CVS?

Yes, I will.

I have one question regarding the handling of RLE surfaces.
I only had a brief look at the SDL source but so far my
understanding
is that each surface can buffer for one RLE compressed image.

My (simple) approach on handling sprites was by having ONE surface
containing all the sprites of my application. (See attached
example).
My app was blitting the appropriate sprite out of the big surface.
While this works well with uncompressed sprites this is suboptimal
for RLE compressed data IMHO.

What is the recommanded way of handling this?
Is the only way of handling this creating
one surfaces one for each single sprite frame?