I am working on a tool, that converts several graphic formats. Therefore
I am looking for informations about what the blitting of 8 bit surfaces
exactly does.
It seems, that there are no informations about that on the net.
What is exactly happening with the colortables, when I blit a 8 bit
surface on an other 8 bit one?
When the source surface contains a color that is not in the dest table,
is it automatically added? What happens when the dest color table whould
have more the 256 colors after a blit?
Are the in indices of the source surface automatically changed to match
the dest color table?
What happens, when the same color is more then once in the table?
I am working on a tool, that converts several graphic formats. Therefore
I am looking for informations about what the blitting of 8 bit surfaces
exactly does.
It seems, that there are no informations about that on the net.
What is exactly happening with the colortables, when I blit a 8 bit
surface on an other 8 bit one?
When the source surface contains a color that is not in the dest table,
is it automatically added? What happens when the dest color table whould
have more the 256 colors after a blit?
Are the in indices of the source surface automatically changed to match
the dest color table?
In a 8bit->8bit blit (which I’m familiar with):
source and destination palettes are left unchanged
the blit uses the closest match color in the destination palette
software (not hardware) palettes are used
The color matching is pretty simple and is done pixel by pixel; for
example, there’s no dithering / Floyd-Steinberg.
If you want the blit to respect the color indices while not respecting
the colors, you can set the same palette to the source and destination
surfaces (with SDL_SetPalette(,SDL_LOGPAL,)).
What happens, when the same color is more then once in the table?
I don’t think this changes anything: the blit just chose the closest
color to the source color in the destination palette.
Cheers,On Sat, Dec 22, 2007 at 12:26:12AM +0100, Christian Meyer wrote:
In my spezial case, I have surfaces where some indices have a spezial
meaning (e. g. marks areas where an animations will be displayed).
So if I understood this correctly, I have to do the following:
When all pixels with index n should be unchaged, I have to make sure,
that n points to the same RGB-value in both palettes.
I think this may not always work. For example, maybe the destination
palette has the same RGB-value than index ‘n’ twice: at index 'n’
and at another index. In that case, maybe the other index will be used.
I’m not sure if there’s an easy way to do that using BlitSurface. If
you only work with 8bit surfaces, maybe you could easily implement
your own Blit function (see http://www.libsdl.org/cgi/docwiki.cgi/Pixel_20Access).
When the color of a pixel should be unchanged, I just have to make sure,
that the RGB-Value exists in the dest palette.
This should work :)On Sun, Dec 23, 2007 at 11:27:56AM +0100, Christian Meyer wrote:
In my spezial case, I have surfaces where some indices have a spezial
meaning (e. g. marks areas where an animations will be displayed).
So if I understood this correctly, I have to do the following:
When all pixels with index n should be unchaged, I have to make sure,
that n points to the same RGB-value in both palettes.
I think this may not always work. For example, maybe the destination
palette has the same RGB-value than index ‘n’ twice: at index 'n’
and at another index. In that case, maybe the other index will be used.
I’m not sure if there’s an easy way to do that using BlitSurface. If
you only work with 8bit surfaces, maybe you could easily implement
your own Blit function (see http://www.libsdl.org/cgi/docwiki.cgi/Pixel_20Access).
When the color of a pixel should be unchanged, I just have to make sure,
that the RGB-Value exists in the dest palette.
This should work
Yes, I think implementing my own blit function will be the easiest way.
Thanks yor your help, and merry Christmas :)> On Sun, Dec 23, 2007 at 11:27:56AM +0100, Christian Meyer wrote:
Just a note to make sure you don’t waste your time: There exist many rewritten blitting routines already. I can only point you to the one I worked on since I don’t know much about the others. Look for SPG_Blit in the SPG_Surface.cpp file in my Sprig library at http://pubpages.unh.edu/~jmb97
From: tvgenial at web.de
Date: Wed, 26 Dec 2007 14:53:57 +0100
Subject: Re: [SDL] Blitting on 8 bit surfaces
Sylvain Beucler schrieb:
Hi,
On Sun, Dec 23, 2007 at 11:27:56AM +0100, Christian Meyer wrote:
Thanks for your answer
In my spezial case, I have surfaces where some indices have a spezial
meaning (e. g. marks areas where an animations will be displayed).
So if I understood this correctly, I have to do the following:
When all pixels with index n should be unchaged, I have to make sure,
that n points to the same RGB-value in both palettes.
I think this may not always work. For example, maybe the destination
palette has the same RGB-value than index ‘n’ twice: at index 'n’
and at another index. In that case, maybe the other index will be used.
I’m not sure if there’s an easy way to do that using BlitSurface. If
you only work with 8bit surfaces, maybe you could easily implement
your own Blit function (see http://www.libsdl.org/cgi/docwiki.cgi/Pixel_20Access).
When the color of a pixel should be unchanged, I just have to make sure,
that the RGB-Value exists in the dest palette.
This should work
Yes, I think implementing my own blit function will be the easiest way.
