Color Keying semantics

  1. When I set the color key for a surface, and also set the RLE
    accelleration, if the surface is in video memory, at every call of
    SDL_LockSurface(), the surface must be depacked to the normal format before
    accessing it. Then, is it packed again in RLE format when I call
    SDL_UnlockSurface(), or just at the next SDL_Blit() or SDL_ConvertSurface()?

  2. If I then call again SDL_SetColorKay() with 0 as flag, is the surface
    immediately depacked, or does it just happen at the next blit…?

  3. If a surface doesn’t require the call of the SDL_LockSurface() function,
    how can I access it directly? Doesn’t it need to be depacked before
    accessing it?

  1. When I set the color key for a surface, and also set the RLE
    accelleration, if the surface is in video memory, at every call of
    SDL_LockSurface(), the surface must be depacked to the normal format before
    accessing it. Then, is it packed again in RLE format when I call
    SDL_UnlockSurface(), or just at the next SDL_Blit() or SDL_ConvertSurface()?
    Its RLE decoded at SDL_LockSurface and RLE encoded at SDL_UnlockSurface.
    You shouldn’t RLE encode video surfaces because it means you can’t use
    hw blits.
  1. If I then call again SDL_SetColorKay() with 0 as flag, is the surface
    immediately depacked, or does it just happen at the next blit…?
    Immediately.
  1. If a surface doesn’t require the call of the SDL_LockSurface() function,
    how can I access it directly? Doesn’t it need to be depacked before
    accessing it?
    If you don’t need to call SDL_LockSurface then the surface isn’t RLE
    encoded so you don’t need to “depack” it.On Thu, Mar 29, 2001 at 01:55:10AM -0800, MetalCoder wrote:


Martin

Bother! said Mistress as she remembered she had left someone tied up.

accessing it. Then, is it packed again in RLE format when I call
SDL_UnlockSurface(), or just at the next SDL_Blit() or
SDL_ConvertSurface()?
Its RLE decoded at SDL_LockSurface and RLE encoded at SDL_UnlockSurface.
You shouldn’t RLE encode video surfaces because it means you can’t use
hw blits.
What do you mean with “video surfaces”. You mean surfaces in VRAM, or only
the visible part of VRAM, or just the surface that will be drawn on the
screen (even in system RAM)?
And, in what sense it means I can’t use hw blits? Isn’t RLE acceleration and
hardware feature?

  1. If a surface doesn’t require the call of the SDL_LockSurface()
    function,

how can I access it directly? Doesn’t it need to be depacked before
accessing it?
If you don’t need to call SDL_LockSurface then the surface isn’t RLE
encoded so you don’t need to “depack” it.
You mean I must always control if I must call SDL_LockSurface()? A surface
could not only need to be locked if it is in VRAM, but also if it is in
system RAM and is RLE encoded? Are there other cases when a surface sould be
locked?

Can you tell me exactly when should I encode surfaces for RLE? If I load
tiles in VRAM for a 2D Platform, I really think the best think would be
encoding them for RLE, right?
If I have a buffer that’s dinamycally modified (for example a starfield, or
plasma effect…) I shouldn’t use RLE…

The only think I don’t undertand is the thing that I shouldn’t encode video
surfaces…

Ah, one last thing. The Docs say that the first time I call SDL_Blit() or
SDL_DisplayFormat() the surface is encoded. Because SDL_DisplayFormat() uses
SDL_ConvertSurface() internally, is the surface encoded also when calling
SDL_ConvertSurface()?–
Marco Iannaccone
@Marco_Iannaccone
ICQ UIN: 18748121 MetalCoder

"What is real? How do you define real? If you’re talking about your senses,
what you feel, taste,
smell, or see, then all you’re talking about are electrical signals
interpreted by your brain."
Morpheus - The Matrix

accessing it. Then, is it packed again in RLE format when I call
SDL_UnlockSurface(), or just at the next SDL_Blit() or

SDL_ConvertSurface()?

Its RLE decoded at SDL_LockSurface and RLE encoded at SDL_UnlockSurface.
You shouldn’t RLE encode video surfaces because it means you can’t use
hw blits.

What do you mean with “video surfaces”. You mean surfaces in VRAM, or only
the visible part of VRAM, or just the surface that will be drawn on the
screen (even in system RAM)?

All of them, I guess… Anyway, RLE doesn’t make much sense for opaque
surfaces such as a back buffer, regardless of where it is.

And, in what sense it means I can’t use hw blits? Isn’t RLE acceleration
and hardware feature?

Nope, at least not on “normal” hardware. RLE is a software based “complex
blit” acceleration method.

If you don’t need to call SDL_LockSurface then the surface isn’t RLE
encoded so you don’t need to “depack” it.

You mean I must always control if I must call SDL_LockSurface()? A surface
could not only need to be locked if it is in VRAM, but also if it is in
system RAM and is RLE encoded?

Right; locking (as I understand the SDL variant of it) is in fact a
"transparent" interface to deal with any case where the surface may not be
in a format that makes sense to the application, where it may not be directly
available to the application, and other similar cases.

Are there other cases when a surface sould
be locked?

Not sure. Anyway, it’s an implementation issue, and appications shouldn’t
rely on anything but possibly that explicitly created software surfaces are
in the expected format, and don’t have to be locked.

Can you tell me exactly when should I encode surfaces for RLE?

(I think I’ll leave that to be given an official answer, just in case…)

If I load
tiles in VRAM for a 2D Platform, I really think the best think would be
encoding them for RLE, right?

Nope, not tiles, unless they’re partially transparent or alpha blended.
(Tiles, as opposed to sprites, are generally rectangular, unless we’re
talking about isometric 3D or other “weird” tile formats.)

If I have a buffer that’s dinamycally modified (for example a starfield, or
plasma effect…) I shouldn’t use RLE…

Correct. (Well, maybe not in all cases; if the surface is updated very
infrequently but used frequently, it might still be viable to RLE encode
it. Don’t do this with big surfaces in a single threaded game, though!)

The only think I don’t undertand is the thing that I shouldn’t encode video
surfaces…

Well, simply because virtually no hardware understands RLE, so the flag will
only confuse matters or reduce performance, except in cases where it’s simply
ignored.

Ah, one last thing. The Docs say that the first time I call SDL_Blit() or
SDL_DisplayFormat() the surface is encoded. Because SDL_DisplayFormat()
uses SDL_ConvertSurface() internally, is the surface encoded also when
calling SDL_ConvertSurface()?

Don’t know for sure…

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Thursday 29 March 2001 17:09, MetalCoder wrote: