Hi!
Does SDL allow having two different palettes on the display surface, one
for rendering and one for display? I want to fade in a picture and the
method I have in mind is as follows:
Let D be the 8-bit display surface, and P be an 8-bit surface with a
different palette containing the picture to be faded in
- Set the “display” palette of D to black and the “rendering” palette
of D to the application’s default palette.
- Blit P -> D. SDL will remap the picture to the “rendering” palette of
D, so the pixel values in D are correct but as the “display” palette
is black, nothing is displayed yet.
- Ramp up the “display” palette of D from black to the same colors as
the “rendering” palette -> the picture fades in.
How do I achive this under SDL? When I simply use SDL_SetColors() on D, I
get an image that only contains one pixel value because the palette is all
black before the blit. And when I SDL_SetColors() the palette of D to the
final palette before the blit (immediately changing it to black
afterwards), I guess I will get a brief “flash” of the full image, before
the fade starts.
Bye,
Christian–
/ Coding on PowerPC and proud of it
/ http://www.uni-mainz.de/~bauec002/
Does SDL allow having two different palettes on the display surface, one
for rendering and one for display?
That’s an interesting idea worth considering. It would definitely make
many palette tricks (fading, palette cycling/animation etc) much easier
and require less workarounds.
Right now you can remap your picture to the final palette and copy the
pixels to the screen surface manually, but that’s cumbersome and
doesn’t take advantage of any hardware acceleration.
The tricky bit is finding a design that’s backwards-compatible and yet
clean. If SDL_SetColors(screen) affects both the logical and physical
palette, we could add a SDL_SetPalette() call that only affects one
of them.
Good idea anyway. Us people who understand the value of 8-bit indexed
modes must stick together. 
Mattias
(Who got a nice fast UltraSparc on the first day of his new job, with
glorious 8-bit budget graphics)
Hi!On Wed, 16 Aug 2000, Mattias Engdegard wrote:
The tricky bit is finding a design that’s backwards-compatible and yet
clean. If SDL_SetColors(screen) affects both the logical and physical
palette, we could add a SDL_SetPalette() call that only affects one
of them.
Yes, this sounds good.
Bye,
Christian
–
/ Coding on PowerPC and proud of it
/ http://www.uni-mainz.de/~bauec002/
Does SDL allow having two different palettes on the display surface, one
for rendering and one for display?
That’s an interesting idea worth considering. It would definitely make
many palette tricks (fading, palette cycling/animation etc) much easier
and require less workarounds.
But would require more overhead and more work for palette changing in the
general case. - it also can’t be represented that way for hardware surfaces.
The easy way to do what he mentioned is:
Leave the palette as it is.
Blit the picture BUT DONT CALL SDL_UpdateRects()
Set the palette to black
Call SDL_UpdateRects()
Fade the palette in
I believe this would work, but I haven’t actually tested it.
Good idea anyway. Us people who understand the value of 8-bit indexed
modes must stick together.
DirectColor, DirectColor, la la la…
Actually, Matthias, it might be nice to support DirectColor visuals as
well as TrueColor visuals. My understanding is that they are the same,
except that you can modify the DirectColor palette for gamma-ramp like
effects.
See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
That’s an interesting idea worth considering. It would definitely make
many palette tricks (fading, palette cycling/animation etc) much easier
and require less workarounds.
But would require more overhead and more work for palette changing in the
general case. - it also can’t be represented that way for hardware surfaces.
Wrong on both accounts. Think about it.
Leave the palette as it is.
Blit the picture BUT DONT CALL SDL_UpdateRects()
Set the palette to black
Call SDL_UpdateRects()
Fade the palette in
This is inflexible, and only works for just this case (and not at all if you
are writing directly to the screen). A very common use of indexed colour
is for small cheap detail animations, where only a few colour cells are
changed (for example, a pulsating red light). With SDL working as it is,
you can’t use its blitting functions at all to draw stuff in such a game
(SDL_SetColors() will invalidate any blit mappings, causing each new
blit to be made remapped).
In other words, you want two kinds of 8bpp blits: Colour-preserving and
index-preserving. Right now SDL only supports the former. With a
logical/physical palette split, both are easily supported in a natural way.
The existing format->palette would be the logical palette, used by
all blitting functions. SDL_SetColors() would change both, guaranteeing
compatibility. SDL_SetPalette() would change either.
DirectColor, DirectColor, la la la…
DirectColor is cool, and easy to use for gamma correcting TrueColor
visuals. (This is perhaps the most common use of DirectColor.)
Some of the PseudoColor palette tricks translate to DirectColor, but
this is rare enough that I don’t think it’s worth supporting.
But would require more overhead and more work for palette changing in the
general case. - it also can’t be represented that way for hardware surfaces.
Wrong on both accounts. Think about it.
Hmm, so there is a single new palette that is associated with the screen
hardware, but not the screen surface? Then the screen surface is displayed
using the screen hardware palette? That sounds right, if I grok what you’re
talking about. It also lends itself well to the application of the new gamma
API in 8-bit modes… ?
DirectColor, DirectColor, la la la…
DirectColor is cool, and easy to use for gamma correcting TrueColor
visuals. (This is perhaps the most common use of DirectColor.)
Yeah, I just figured out how to do that. See my next message about
gamma ramps.
See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software