Palette question

[Wolfstarr]

So as my photoshop and colouring skills are limited I have been experimenting with a visual way of coming up with suitable palette swaps.  My current effort is https://www.sidequests.co.uk/ufo/palette_ufo_ethereal.htmland ideally want to have every vanilla unit analysed so I can look at palette swaps.  As you can see my tool analyses the specific number of pixels and their RGB values.

What I am struggling to understand at the moment is that some of the colours for the ethereal do not exist on the core 200 odd on the PNG sample of the battlescape palette.

On the wiki it says that "Each RGB value has a maximum intensity of 63/x3F", please could someone explain what this means? Does it mean that the RGB value from within the PNG palette https://www.ufopaedia.org/index.php/PALETTES.DAT can increase by 21 on each of the R, G, B values respectively?

Or is this a measure of the shades of colors that exist between each one of the grid colours?

Thanks to any who can shed light on this!

[Starving Poet]

Well, for starters the pallete is 256 colors - 16 colors each with 16 shades with 0 being transparent.  Be careful using a program that 'optimizes' palletes, it will screw up the pallete index and break all your colors -

Here's a link to the .pal files:  https://openxcom.org/forum/index.php/topic,1557.msg14258.html#msg14258

As far as programs go, I'm a big fan of asperite when doing this sort of work.

What the 63/x3F means is that your RGB values increment by multiples of 4 when working with your standard 0 -> FF colors. ( 0, 4, 8, C, 10, 14, 18), etc

[Wolfstarr]

Thanks poet

I've been tearing my hair out over last couple of days!

P.S. Loved watching your playthroughs on YT!

[Solarius Scorch]

Have a look at this, if you haven't yet:

falkooxc.pythonanywhere.com/palconvert

It's an X-Com palette conversion tool, but also a good way to browse through all the palettes.

[Wolfstarr]

Thanks Solarius

So are there 200k colours we can use or are we limited to 256 specific colours each with 16 shades?

I just build a webpage to display every permutation of 8 bit colours and it took 20 mins to render in browser, with 63 colours per line and over 3,000 lines I won't be doing this soon!

In my case with the ethereal as an example I used pckview to extract them with the XCOM palette but some of the colours don't exist in pallete and fluctuate slightly.

[Starving Poet]

In vanilla / nightly you're limited to those specific palletes - I haven't used it, but I do believe OXCE+ you can use custom palletes, as long they are in the same format.  Everything is done via indices.

[Wolfstarr]

Thanks Poet, sorry to sound thick is that:

1. 256 colours
2. 256 colours with 16 shades

If 2 to generate the shades are we simply adding 4 to each rgb value to create each distinctive shade?

Thanks again for your patience

[Arthanor]

just 256 colors, that's 16 colors of 16 shades, as shown by this image (although it's slightly off I think):



with index 1, the top left corner, being actually transparent, not white. That pixel is sometimes mapped to a bright green or pink by modders, as OpenXCom doesn't really care what palette you use, just that you give it an image with 256 indices which it assigns colors to since the palettes are hardcoded.

The shading for each of the 16 colors is done in a slightly odd manner which gives XCom it's signature look and has so far not quite been reproduced as a "darkening algorithm".

[Solarius Scorch]

By the way Sidey, if you want to play around with palettes, my personal wish is better reds. They're not bad as such (no colour is), but there are no bright, juicy reds - any red colour looks brownish in comparison after it is converted to Battlescape. I don't know if it can be done, or if it wouldn't damage the original look of red items, but it would be nice if someone tried - my hands are already full with other stuff.

[RSSwizard]

On the wiki it says that "Each RGB value has a maximum intensity of 63/x3F", please could someone explain what this means? Does it mean that the RGB value from within the PNG palette https://www.ufopaedia.org/index.php/PALETTES.DAT can increase by 21 on each of the R, G, B values respectively?

Im not sure but I BELIEVE it may have something to do with how some VGA palette handling was done back in the early 90s. I encountered this first with Fractint since I used its internal palette editor extensively.

That being, even though you have 256 colors to work with, each of the channels RGB are limited to 64 Shades each.

So the RGB values would be in multiples of 4 and your actual choices to choose from would be 0-63 in each of the R, G, B fields.

So you would have values like 53, 61, 23 for some kind of faded greenish yellow. This would translate to R212/G244/B92


There are alot of older games that you can see this behavior on by checking the white color on their palette or anything that is saturated, you will find that the maximum value is actually 252 and think "thats odd, why isnt it 255? I guess its close enough but its kinda off?"

I dont know why they did this, probably to save memory, but thats one thing I noticed. So when you said "63" thats what tripped my recognition.

[Wolfstarr]

Cool thanks for replies everyone

Yeah I've been experimenting with colours, working out all the permutations of increasing rgb values by 4 was fun.  My webpage is nearly 40 meg that displays them all so can see how this would suck memory.

Been quite interesting actually to learn about how colours work in general.

Solarius, Il conduct some experiments and see what I can come up with

[Warboy1982]

just for the record, custom palettes will work in the nightlies as well

[RSSwizard]

Cool thanks for replies everyone

Yeah I've been experimenting with colours, working out all the permutations of increasing rgb values by 4 was fun.  My webpage is nearly 40 meg that displays them all so can see how this would suck memory.

Been quite interesting actually to learn about how colours work in general.

64x64x64 is
262,144 colors

Which for the 25% savings on memory compared to 8bit per channel is actually Pretty Dang Good since its "possible" to notice the difference, but its much less pronounced than it is with 15/16 bit graphics (im pretty sure my netbook has a 16 bit display and just hardware downconverts 24bit in realtime because it will stipple colors that should be solid).

So thats like getting 25% of your memory back for free, back in the days of 512kb conventional memory and (maybe) 2Mb of Ram that was a killer deal.

The Trident SVGA video card my dad had installed on our x286 had 1Mb of video ram. That was pretty dam awesome though it was entirely incapable of displaying HiColor or TrueColor.

Im not sure but I think the original NES gaming system, based on my observations with using an old emulator that allowed me to mess with the colors . . . actually used 4 bits per channel or worse.

It only displayed 16 colors at a time, but from the color mixer selection it seemed that all of the colors it could switch out were actually mapped or had noticeable increments on its sliders.

Even a 16 color EGA display can adjust the individual color values usually by 64 shades each. So the original NES game system is actually a little bit less capable than EGA is. Though with the optimized way they programmed the games back then you really wouldn't notice (like the siezure inducing screen flashes, and the palette cycling on those zelda fireballs and sword bolts that somehow looked pretty awesome but at 60hz framerate made them look ultraviolet and stuff).

[yrizoud]

64x64x64 is
262,144 colors

Which for the 25% savings on memory compared to 8bit per channel is actually Pretty Dang Good since its "possible" to notice the difference, but its much less pronounced than it is with 15/16 bit graphics (im pretty sure my netbook has a 16 bit display and just hardware downconverts 24bit in realtime because it will stipple colors that should be solid).

So thats like getting 25% of your memory back for free, back in the days of 512kb conventional memory and (maybe) 2Mb of Ram that was a killer deal.

Sorry but this is irrelevant. Here we're talking 18bits per COLOR, not 18bits per PIXEL. Since there are only 256 colors in the screen's palette, the potential gain of 18bit vs 24bits would be a total of 192 bytes, in all resolutions. For PC components, memory alignment is extremely important for quick access, so in practice, there was actually no gain at all : the VGA palette was stored and accessed as one byte per component. The top two bits were unused.