When I perform a blit from and 8-bit surface to another 8-bit surface,
aren’t simply copied the color indices, but, for each color from the origina
surface, the RGB values are compared with the valus of the colors of the
other surface, to find the similar one, for having the most similar color.
This is good, but has 2 drawback, at leas, I think:
- isn’t performance affected, this way?
- when I want to perform a fade in I have some problems. I should:
a) set the dest palette to back
b) blit to the dest surface from the original one
c) then increment the components until they reach the final color
The problem is that when I perform the blit, I don’t get the right
result, cause indices aren’t simply copied,
'cause SDL looks for a color in the dest palette similar to the one in
the original one…
How can I avoid this behavior?–
Marco Iannaccone @Marco_Iannaccone
ICQ: 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
How can I avoid this behavior?
Don’t use indexed color modes, use real color 
~jeffrey :j
Don’t use indexed color modes, use real color
So, this is the normal behaviour with indexed modes and cannot be
overridden?–
Marco Iannaccone @Marco_Iannaccone
ICQ: 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
“Marco Iannaccone” wrote in message
news:95418m$jrh$1 at ftp.lokigames.com…
Don’t use indexed color modes, use real color
So, this is the normal behaviour with indexed modes and cannot be
overridden?
You could do the blit manually by locking both surfaces and using memcopy.
You could set the destination surface palette to the source palette, perform
the blit, and convert it back. Or you could try to get this feature into
SDL by writing and submitting a patch.–
Rainer Deyke (root at rainerdeyke.com)
Shareware computer games - http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor
When I perform a blit from and 8-bit surface to another 8-bit surface,
aren’t simply copied the color indices, but, for each color from the origina
surface, the RGB values are compared with the valus of the colors of the
other surface, to find the similar one, for having the most similar color.
This is good, but has 2 drawback, at leas, I think:
- isn’t performance affected, this way?
- when I want to perform a fade in I have some problems. I should:
a) set the dest palette to back
b) blit to the dest surface from the original one
c) then increment the components until they reach the final color
The problem is that when I perform the blit, I don’t get the right
result, cause indices aren’t simply copied,
'cause SDL looks for a color in the dest palette similar to the one in
the original one…
You can use the new gamma functions in SDL to perform a fade that
doesn’t affect the palette. These functions are gauranteed to work
on 8-bit video modes.
Here’s the new Maelstrom fading code:
void
FrameBuf:: Fade(void)
{
float gamma;
if ( faded ) {
for ( gamma=0.1; gamma<1.1; gamma += 0.1 ) {
SDL_Delay(20);
SDL_SetGamma(gamma, gamma, gamma);
}
} else {
for ( gamma=1.0; gamma> -0.1; gamma -= 0.1 ) {
SDL_Delay(20);
SDL_SetGamma(gamma, gamma, gamma);
}
}
faded = !faded;
}
To answer your question, if you want to copy data between surfaces
without mapping the colors, you have to copy the data yourself. This
may be addressed in the upcoming SDL 1.3 API.
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
When I perform a blit from and 8-bit surface to another 8-bit surface,
aren’t simply copied the color indices, but, for each color from the origina
surface, the RGB values are compared with the valus of the colors of the
other surface, to find the similar one, for having the most similar color.
Right. SDL_BlitSurface preserves colours, not pixel values
- when I want to perform a fade in I have some problems. I should:
a) set the dest palette to back
b) blit to the dest surface from the original one
c) then increment the components until they reach the final color
The problem is that when I perform the blit, I don’t get the right
result, cause indices aren’t simply copied,
'cause SDL looks for a color in the dest palette similar to the one in
the original one…
that’s what SDL_SetPalette is there for, so you can have identical source
and destination (logical) palettes so that blits are quick and work the
way you expect. See test/testpalette.c for an example of how to use this
Here’s the new Maelstrom fading code:
[snip]
for ( gamma=0.1; gamma<1.1; gamma += 0.1 ) {
SDL_Delay(20);
SDL_SetGamma(gamma, gamma, gamma);
}
Did you really prefer doing it that way? It’s non-linear and I think it
didn’t look natural. I’d prefer something like
const int max = 32;
Uint8 ramp[256];
for(int j = 1; j <= max; j++) {
int v = faded ? j : max - j + 1;
for(int i = 0; i < 256; i++)
ramp[i] = i * v / max;
SDL_SetGammaRamp(ramp, ramp, ramp);
SDL_Delay(20);
}
faded = !faded;
Did you really prefer doing it that way? It’s non-linear and I think it
didn’t look natural. I’d prefer something like
[code snipped]
You’re right, your version looks very nice. Speeded up a little and
adjusted for the latest API, the code looks like this:
const int max = 32;
Uint16 ramp[256];
for ( int j = 1; j <= max; j++ ) {
int v = faded ? j : max - j + 1;
for ( int i = 0; i < 256; i++ ) {
ramp[i] = (i * v / max) << 8;
}
SDL_SetGammaRamp(ramp, ramp, ramp);
SDL_Delay(10);
}
faded = !faded;
Thanks!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software