Alright, I'll use an example from a Sonic game why software parity is my goal here.
http://3.bp.blogspot.com/-TV0WD2-kH...EGAGenesisClassics+2012-09-04+19-53-36-02.bmp
The water color is not a modulation of the color underneath with a tint color. It's a mapping from some color index to an alternative color to have the appearance of translucent water. The mapping function for tint blending, shown below:
where C is a True Color, to achieve the same visual aesthetic,
is not quantifiable. We know what the end result should be, but the palettes used for mapping in the indexed function are not on a quantifiable, functional curve. There's a reason why fixed-func OpenGL doesn't look like software at all, and no amount of adjusting tints will ever approximate this well.
In a similar way, colormapping for lighting is not quantifiable.
SRB2 is and has always been about putting classic Sonic feel in 3D, and I think the software renderer's perceived faults with palettes actually accomplishes the visual aesthetic of class Sonic very well, particularly with 255-bright sectors. The reason for this, is
Boom actually has essentially the same mapping function for translucency effects (which we inherent from in Doom Legacy for software).
Personally, I think tinting surfaces with true color blending actually washes out a lot of the color. It's appropriate for photorealism, but Sonic is not photorealistic. It's a very colorful game.
I do not think it is appropriate to get/keep photorealistic blends in the OpenGL renderer when the software renderer doesn't do it and maintains its visual color palette well without it.
There's a fundamental difference between the Sega Genesis and the Doom Legacy engine, though. The Genesis, at a specific hblank, switches to another hand-crafted palette. Doom Legacy, meanwhile, tints the entire 256-color palette and then automatically maps each entry back to the closest approximation from that 256-color palette. The two situations are thus incomparable: given that the Genesis palette is handmade and can reference colors not existent in the original palette, it can easily preserve all detail unless the designer explicitly chooses two palette entries the same color; Doom Legacy's palette, meanwhile, is autogenerated and will very likely cause loss of detail, given that A) the algorithm can only make a decision mathematically instead of aesthetically (machines aren't generally known for understanding aesthetics), and B) the end result palette is limited to a subset of the original 256-color palette, a restriction the Genesis palette doesn't have (as mentioned prior). I mean, if you take our 32-color gray palette range (0-31) and then map it to our 8-color fuchsia palette range (192-199), the pigeonhole principle makes it fairly plain you're going to assign more than one entry in the gray range to a single entry in the fuchsia one, losing whatever detail that had relied on those differences in shades of gray.
On that note I fail to see how Boom using the same lossy approach tinting is supposed to convince me this is a good idea. (I mean, you must've thought it would, you even bolded it!) It
also only came about because they were stuck with an 8-bit color limitation that is irrelevant to OpenGL, and has the same "must map to the existing 256 colors" limitation that Doom Legacy's colormaps have (with an added plus and minus; the upside being that the user gets total control over what that mapping
is, since it's not autogenerated, but the downside being you have to actually
stand in the sector for the colormap to apply - it was only intended for fake floors to simulate water and such).
Your "washed out" argument doesn't even make sense. Look, here's GFZFLR02 and TAILSA2A8 under a 50%-transparent #0000FF tint, which I'm pretty sure is basically how Legacy auto-generates its colormaps. Left is untinted, middle is tinted in truecolor, right is then translated to SRB2's palette using the index with the closest color (again, like how Legacy auto-generates colormaps):
In both cases, the middle pictures preserve all the detail of the original detail while appropriately coloring things blue. The pictures on the right - which I'll remind everyone is what's apparently being aimed for here - show significant loss. GFZFLR02 had a good 10-or-so shades in it originally; now that's down to
4, losing a lot of the texture it had originally had. And TAILSA2A8; the underside of his tail went from an expected shade of purple to a dark gray, while the shine on his head is now a pale gray that stands out like an eyesore from the surrounding orange. And this is supposed to be better, how exactly?
At the end of the day, you're still continuing to argue that the correct approach here is to make OpenGL look worse in the pursuit of "palette parity" I don't recall anyone asking for, and then make those changes mandatory, screwing over those of us who stuck with OpenGL not merely because it has perspective correction, but because it
looks better. Software was only recommended because nobody on the team was particularly good at keeping OpenGL up to date; that doesn't translate to "let's force all of its shortcomings into OpenGL" in the slightest bit.
What's next? Do we remove perspective correction from OpenGL, in favor of making all walls perfectly vertical, causing severe distortion when you look too far up/down? Software did it, so clearly it's the right thing to do!
Parity!
(Also, never, ever use the Doom wikia. They moved to
doomwiki.org ages ago.
It's a long story.)
