How does RLE encoding work in detail?

SDL Development
1

Hi!

I am trying to integrate the RLE encoding into my program. But I have a
few questions about the RLE encoding.

Does it have to do anything with the colorkey?
Is every color encoded, or just the color key?

Will the surface get reencoded, when changing the color key?

Can the RLE encoding be used without a color key on the surface?

When i call SDL_SetColorkey(), SDL_SetAlpha etc., does it reset the RLE
flag, if it is not passed? So, when using a RLE encoded surface, do I
have to pass the RLE flag, to all functions, that accept surface flags?

Thanks for your answers :slight_smile:

Christian

2

Noone else has answered this, and it’s something I was interested
in hearing the answer to, so I’ll try to, based on what I’m seeing
in the header files (e.g., SDL_video.h)

I am trying to integrate the RLE encoding into my program. But I have a
few questions about the RLE encoding.

Does it have to do anything with the colorkey?

Yes. RLE is used for colorkey and alpha blits.

Is every color encoded, or just the color key?

That I’m not sure of. I’d assume so, otherwise it’d be kind of
difficult to RLE any of it. I believe RLE’ing is generally useful
for low-color surfaces (things you’d use for sprites). When you
start getting into more color variation across pixels, your encoding
will likely come out as: “one pixel of a,b,c. one pixel of x,y,z.” etc.

It’s still probably useful when you’ve got large transpareny zones.

Note, though, that if a surface is RLE’d, it must be locked.
(SDL_MUSTLOCK() is a macro that checks whether the surface is RLE accel’d,
among other things… such as it being a hardware surface).

Will the surface get reencoded, when changing the color key?

I think that would depend on the above. If all pixels are RLE’d,
then there’d be no reason to re-encode if the colorkey changed.
It’d simply just skip a different batch of pixels when blitting
(the once which match the transparency color key).

Can the RLE encoding be used without a color key on the surface?

It see that SDL_SetAlpha() and SDL_ConvertSurface() also accept
the SDL_RLEACCEL flag, so it doesn’t specifically need to be
color-key.

When i call SDL_SetColorkey(), SDL_SetAlpha etc., does it reset the RLE
flag, if it is not passed? So, when using a RLE encoded surface, do I
have to pass the RLE flag, to all functions, that accept surface flags?

The header file seems to suggest so:

SDL_SetColorKey()…
“SDL_RLEACCEL requests RLE acceleration for the surface if present,
and removes RLE acceleration if absent.”

SDL_SetAlpha()…
“OR:ing the flag with SDL_RLEACCEL requests RLE acceleration for the
surface; if SDL_RLEACCEL is not specified, the RLE accel will be removed.”

SDL_ConvertSurface()
“The ‘flags’ parameter is passed to SDL_CreateRGBSurface() and has those
semantics. You can also pass SDL_RLEACCEL in the flags parameter and
SDL will try to RLE accelerate colorkey and alpha blits in the resulting
surface.”

Also… SDL_DisplayFormat() uses SDL_ConvertSurface() internally.

Thanks for your answers :slight_smile:

I hope that shed some light… and that if I got anything wrong, someone
else will finally respond. :wink: Heheh.On Mon, Apr 06, 2009 at 05:36:06PM +0200, Christian Meyer wrote:

–
-bill!
Sent from my computer

3

If I were implementing an RLE mechanism, I would encode it as a series
of alternating “runs” with a byte or two encoding the length of the
"run," and then either one value (for a homogeneous run) or 'length’
many values (for a heterogeneous run.)

But this is just speculation and doesn’t really help the OP!On Wed, Apr 8, 2009 at 9:23 PM, Bill Kendrick wrote:

When you
start getting into more color variation across pixels, your encoding
will likely come out as: ?“one pixel of a,b,c. ?one pixel of x,y,z.” etc.

–
http://codebad.com/

4

Noone else has answered this, and it’s something I was interested
in hearing the answer to, so I’ll try to, based on what I’m seeing
in the header files (e.g., SDL_video.h)

Dig a bit deeper, and you’ll find pretty interesting stuff, such as
the comment at the top here:

http://www.libsdl.org/cgi/viewvc.cgi/trunk/SDL/src/video/SDL_RLEaccel.c?view=markup

Interpreting this, tells us…

Is every color encoded, or just the color key?

That I’m not sure of. ?I’d assume so, otherwise it’d be kind of
difficult to RLE any of it. ?I believe RLE’ing is generally useful
for low-color surfaces (things you’d use for sprites). ?When you
start getting into more color variation across pixels, your encoding
will likely come out as: ?“one pixel of a,b,c. ?one pixel of x,y,z.” etc.

It’s still probably useful when you’ve got large transpareny zones.

The RLE is used to skip the colorkey’d pixels, not to compress the
image. This is basically so that you can streamline the software blits
by removing a conditional from the blitting loop. Once you do that,
you can even use something really dumb (but optimized), like memcpy(),
to copy the non-colorkey’d pixels. Mis-predicted branches are
expensive on modern CPUs, so cutting a conditional that could go
either way “randomly” for every pixel is a big win.

Note, though, that if a surface is RLE’d, it must be locked.
(SDL_MUSTLOCK() is a macro that checks whether the surface is RLE accel’d,
among other things… such as it being a hardware surface).

And locking them will be somewhat expensive, as it needs to expand it
to non-RLE format, then when you unlock it, will RLE encode it again
(blitting to a hardware surface might have the same cost too, BTW, so
RLE isn’t always a win, I suppose), much like what happens with
hardware surfaces on some modern video cards.

Will the surface get reencoded, when changing the color key?

I think that would depend on the above. ?If all pixels are RLE’d,
then there’d be no reason to re-encode if the colorkey changed.
It’d simply just skip a different batch of pixels when blitting
(the once which match the transparency color key).

Since the RLE encoding for colorkey’d surfaces is "
", then it would have to be re-encoded, yes.

Can the RLE encoding be used without a color key on the surface?

It see that SDL_SetAlpha() and SDL_ConvertSurface() also accept
the SDL_RLEACCEL flag, so it doesn’t specifically need to be
color-key.

On a plain old surface, RLE encoding would do nothing at all, it would
just add a small header to every scanline (0 skip, the run size, then
the data), or every 256 pixels, whichever comes first, and
locking/unlocking would require conversions, so it definitely sounds
like lossage to me.

I’m not entirely sure why you’d use RLE encoding with a per-surface
alpha (there’s no conditional there, every pixel is needed), but for
per-pixel alpha, runs with alpha == 0 and alpha == 255 are encoded, so
fully transparent pixels are not looked at, and fully opaque pixels
are just blitted the “dumb” way, without blending.On Wed, Apr 8, 2009 at 9:23 PM, Bill Kendrick wrote:

–
http://pphaneuf.livejournal.com/

5

If you are looking for a way to actually compress the image and speed up
blits, you could just make your own RLE encode and blit functions.

You may want to check out the windows bitmap RLE4 and RLE8 algorithms. You
can find these here under “Image Data and Compression”:
http://www.fileformat.info/format/bmp/egff.htmOn Thursday 09 Apr 2009 12:05:03 Pierre Phaneuf wrote:

On Wed, Apr 8, 2009 at 9:23 PM, Bill Kendrick wrote:

Noone else has answered this, and it’s something I was interested
in hearing the answer to, so I’ll try to, based on what I’m seeing
in the header files (e.g., SDL_video.h)

Dig a bit deeper, and you’ll find pretty interesting stuff, such as
the comment at the top here:

http://www.libsdl.org/cgi/viewvc.cgi/trunk/SDL/src/video/SDL_RLEaccel.c?vie
w=markup

Interpreting this, tells us…