In a somewhat similar vein to the recent discussion about Pro Motion’s linear handling of RGB values, it’s been known for a long time that older games consoles don’t always map their limited 12-bit/9-bit/6-bit/etc colorspace into the pure linear 24-bit RGB values that Pro Motion’s reduced color range generates (i.e. step-by-36 for a 9-bit RGB palette).
This is particularly noticeable on consoles such as the PC Engine where a LOT of work has been done to show that the manufacturer specifically tweaked the theoreticaly-9-bit RGB color range for their actual YUV composite output.
Would it be possible to have Pro Motion use a 4096/512/64 entry lookup table to map the 24-bit output color values whenever a reduced range of colors has been enabled in the Color Constraints?
This is what modern console emulators do (in reverse) in order to get accurate color output.
I’m not asking for any changes in Pro Motion’s internal logic or color handling of paletted pixels (step-by-36 is still fine and excellent for processing afterwards), just an extra (or different) palette lookup step in the output stage to the PC’s monitor, which may be similar to what is already done to turn the 8-bit pixels into 24-bit RGB for Windows.
That’s a very interesting point. I’ve been working on a game called UrbX Warriors recently for the Spectrum Next which has a 9bit palette. Pro Motion works flawlessly with this as I have the constraints set as 3,3,3, for the RGB range, but… I know other machines like the Sega Mega Drive, PC Engine and Atari ST though sharing the same 9bit palette probably do have varying differences between them.
Without knowing what these variations are I can’t see how this would be achieved unless some form of manual control was implemented when setting up the colour constraint variables. Even this could be open to variances as ne persons screen will differ from another.
For me personally there are too many variables to be too worried about the final output though I do find it fascinating.
It should be fairly easy to implement IF Pro Motion is blitting an 8-bit paletted image to the Window, it’s just a case of allowing the user to specify a custom 512-entry set of RGB values for their color range, and looking up the 24-bit RGB value to use in there instead of doing (R * 36), (G * 36), (B * 36) which is what Pro Motion looks like it is currently doing for a limited color range when you set a 3-bit-per-channel palette.
This would ONLY be for the output to the computer’s Window, Pro Motion can, and honestly should, just keep on using and showing the math and RGB values that it’s already using.
Artists just want to deal with an 8 level slider, and programmers have been using the (n * 36) math in their toolchains for years.