I ran across an oddity while working on the true colour version of DotB. It appears that the hud font gets palletised in GZDoom, though it appears correctly in Zandronum. The Intermision font also appears to get palettised in both engines.
I could correct for this in GZDoom by using a fontdef lump for the respective fonts with the UNTRANSLATED flag, however this was incompatible with Zandronum.
Nothing here to test. AFAIK this has always been like that, I wonder if Zandronum made some changes to the font system. But the least we need is a runnable example.
To build the translations, the font loader first creates a luminosity table of the font, this is being done on the paletted content, of course, not the true color version. Once that is done it builds a translation table - again not doing this on the real content but the luminosity remapped version of it - and last but not least when requesting the bitmap, the data is given in a form that makes it impossible for the texture to know that it's really the native image that's being requested.
This all is a relic from very old times when all ZDoom had was the software renderer - this entire code was written with zero foresight and zero extensibility. The 'untranslated' translation is not what one might expect - because it doesn't use the native palette as reference but the luminosity remap. So once the font character is requested to produce some image data, there is no way to get what you need.
I still haven't managed to get into it deep enough to shortcut the case for untranslated display, mainly because the code is not well structured and encapsulated. Instead of having an abstract base font class we instead have a base class which handles the problem case and several derived classes which piggyback on the same code but have to handle this special case just like any other translation. So, if I try to make changes to the untranslated base case it will immediately break all fonts not based on regular images.
Ultimately it all boils down to passing the raw data into the system too early, once I come to the point where to make a decision I do not have what I'd need to do it right. This has been a constant problem with lots of old Doom and ZDoom code which was written in a different era - when future-proofing code was not high on the agenda -, it seems.
Writing that text actually gave me an idea. It seems to work now. However, since I had to make the change in a work branch that won't make it into the next release this will most likely only be in the next minor release after the upcoming one.
