Squeezing a little bit more contrast/colors out of 0..63

[Skybuck]

I just noticed the conversion from 0..63 to 0..255 is not perfect.

   for (int i = 0; i < _count && palFile.read((char*)value, 3); ++i)
   {
      // Correct X-Com colors to RGB colors
      _colors.r = value[0] * 4;
      _colors.g = value[1] * 4;
      _colors.b = value[2] * 4;
      _colors.unused = 255;
   }
   _colors[0].unused = 0;

Assuming the original/input palette range is indeed 0..63 then this gives:

63 * 4 = 252

So that means the brighest setting 63 is not using the brighest 255.

To correct this floating point calculation would have to be used with a little bit more exact conversion value.

The conversion value would be:

255 / 63 = 4,047619047619047619047619047619

Anyway, is there a reason why this conversion value is not used ? Is there any adventage of reason to limit it to 0..252 ?

(Perhaps OpenXcom is a little bit darker than the original because of this... not sure...)

(Reminds me of call of duty 4 modern warfare, when changing the gamma value the color range would be limited to 0..232 or something similiar and the developers never noticed it lol... I did tell somebody... I discovered because of a video codec experiments... and simply calculating something resembling a "histogram" over call of duty test images/screenshots).

Now I am going to test this "proper conversion" idea out, to see if I can notice any differences, maybe I make two nice screenshots to compare versions...

Interesting link, explaining some possible conversion formulas:

https://moddingwiki.shikadi.net/wiki/VGA_Palette

I don't believe this part though:

"Performing the multiplication before the division removes the need to use floating point numbers and minimises any rounding errors. "

Easy example:

62 * 255 / 63 = 15810 / 63 = 250,95238095238095238095238095238

I am pretty sure that an integer division would round this down to 250 which is not what I would want because it's closer to 251 ?!?

Would rounding the nearest be bad ? and creating a shift in the palette ? I am not so sure...

[SupSuper]

Changing the color formula now would just potentially break every mod for little benefit.

[Skybuck]

Changing the color formula now would just potentially break every mod for little benefit.

Hmm why would it break it ? Why would mods be aware of the red green blue values that are behind the vga palette indexes ? In principle as far as I know it should not affect anything except the color that is outputted towards the monitor.

Except if mods actually look at and process the actual R,G,B values themselfes ?! Is that what you are getting at ? Can you give at least 1 example of a mod that does this ?

I cast big doubts on this hypothesis because the entire game is basically in 8 bit anyway...

Are there any other reasons I may be over looking ?

I tested it extensively... both, the 3 value difference in Delphi, it's noticeable/shimmering so that makes it worth while for me to change this palette to full range from 0..255.

I did notice maybe a strange bug on the cyberdisc top side seems to go missing, not sure if it's because of this full range palette or if that is a unrelated bug.

I do believe it maximizing colors and keeping it as accurately as possible, otherwise color wash out starts sneaking in... little bit by little bit

I will do a git pull request for fun:
https://github.com/OpenXcom/OpenXcom/pull/1380