Palette

[SharkD]

Does the file "pure colors.pal" in the Image directory contain a list of all the colors that images contain after they've been converted to 8-bits? Oddly, it lists fewer than 256 unique colors.

Also, what is the file "touchup.pal" for?

[Joseph Hewitt]

Those are the color palettes for an old version of Ultimate Paint I was using to edit the sprites. I should probably delete them.

[SharkD]

Are the colors listed in it correct, though?
I just did a quick test using cosplay, and the output image had only 44 unique colors.

[Joseph Hewitt]

The colors probably aren't correct, no. The exact colors used by the substitution procedure can be seen in the GearHead files/graphics/GH-Color-Test.png file. If you need an exact reference, that's probably the best one to use.

[SharkD]

I did a similar test with a different set of images. However, the result only had 44 unique colors. Is this right? It seems kind of low.

[Joseph Hewitt]

According to Tung Nguyen's test, it can display up to 63 different colors plus transparency. I suspect that the SDL 24-bit source to 256-color destination renderer sacrifices color accuracy in exchange for speed. Here's the relevant post from the dev group:

http://games.groups.yahoo.com/group/gearhead_dev/m essage/3981

[SharkD]

I wonder if there's a way to bump it to 256 from 64?

Anyway, the reason I asked in the first place was that it would be a lot easier to check the post-swap colors if I had a palette file I could just load over my image.

[Tung Nguyen]

It goes a bit like this:

1 pure blue
63 shades of grey, from black to white
64 shades of red, from black to pure red
64 shades of yellow, from black to pure yellow
64 shades of green, from black to pure green

Those shades are evenly spaced AFAIK, but I'd need to look into the source to get the exact colours.

[SharkD]

Quoting: Tung Nguyen

It goes a bit like this:

1 pure blue
63 shades of grey, from black to white
64 shades of red, from black to pure red
64 shades of yellow, from black to pure yellow
64 shades of green, from black to pure green

Yes, but when I took a screen capture after I ran the above image through cosplay, what I got is 44 colors--which is a lot less than the 256 colors you listed.

[Joseph Hewitt]

Quoting: Tung Nguyen

It goes a bit like this:

Yes, but remember that test you did? Not all of the colors are being used, and we couldn't figure out exactly why. Maybe this is something I should ask about on the SDL lists.

[Tung Nguyen]

Test? Hmm... nope. But then again, I have a really horrible memory. I read your comment on having only 64 colours, and I was like "That doesn't sound right".

Wait... I think I might know what's happening. That test image has more colours than is normally supported, so obviously it's being reduced to fit into a palette. But SDL doesn't know which colours are important to GearHead: it just picks the ones that make the most difference image-wise. That's my hypothesis, anyway.

What happens if you turn the bottom half of the test image pure blue?

[SharkD]

All shades of blue get converted to some shade of gray. I assume pure blue becomes transparent, but have no way to confirm this as the background in cosplay happens to also be black.

[Joseph Hewitt]

I just did a new test here. It just compares one green square to another, but you can see plainly what's going on.

URL
The test image has about 256 shades of green in it, going from (0,1.0,0) to (0,0,0). You'd expect the color switched one to have 64 shades of green, but instead only 7 are visible.

It seems from this that the BlitSurface routine picks the first palette entry it finds that's "close enough" to the source color when rendering to a paletted surface.

How to work around this? Well, there was a suggestion made earlier to do the color swapping manually with a pixel-by-pixel brute force routine. This would likely be far slower than the current method but since recoloring is a  one-time expense it probably wouldn't be too bad. The thing I don't like about it is that I've had bad experiences with GetPixel and SetPixel in SDL in the past.

[SharkD]

Maybe a brand new sprite could be generated once every time you change the mecha's colors, but never any other time.

Unfortunately, seperate sprites would need to be stored on the harddrive for each faction's colors.

It seems from this that the BlitSurface routine picks the first palette entry it finds that's "close enough" to the source color when rendering to a paletted surface.

I was looking through the source code and found a lot of (t*4) operations being used as table indices. Maybe this is the problem, as 256/4=64?

Also, I created a wiki page on this subject:
http://ghwiki.chaosforge.org/index.php/Development     :Artwork:Palette-swapping

[SharkD]

Quoting: Joseph Hewitt

How to work around this? Well, there was a suggestion made earlier to do the color swapping manually with a pixel-by-pixel brute force routine. This would likely be far slower than the current method but since recoloring is a one-time expense it probably wouldn't be too bad. The thing I don't like about it is that I've had bad experiences with GetPixel and SetPixel in SDL in the past.

Since all images are flattened to 8 bits in SDL anyway, is there any reason why the sprites themselves shouldn't be 8 bits to begin with? This would remove a step in the rendering process, thereby freeing up resources for other things (as well as decreasing the game's download size).

It would also allow the palette-swapping to be done in a more controlled environment as long as the source images use the same palette.