ZDoom

Yes, precisely.

So, for a paletised png, ZDoom looks at the image palette and matches the entries in it to the game palette rather than looking at each pixel in the image and doing the match there (which, presumably it has to do for a true colour image)?

If so, I can see how that would be less expensive and get more accurate results too. thanks for the info.

A full lookup of 256 colors is a vastly different thing than a lookup of, say 128x128 separate pixels. It's affordable when using a palette.

Fair enough. It's a minor problem. It would be nice if it could be addressed but if doing so would have an appreciable performance hit I can understand not addressing it. I guess it's just something to keep in mind when using true colour images.

Just out of curiosity, what is done differently with paletised images? I don't mean pngs in the Doom palette. I mean an 8 bit png that is using a palette other than the game one. If such an image has an area that is R11G23B7, it gets mapped correctly in the Doom palette. So, there must be something different being done to handle the palette matching in such images.

It's too slow, plain and simple. To do a proper lookup it'd have to check each and every pixel in the image for each and every color in the palette. Right now the lookup is one simple indexing operation, it'd have to be changed into a loop that runs 255 times, once for each palette entry.

So is there any way to deal with a known inaccuracy such as this or would having any specific colour check make things prohibitively slow?

It's not really bothering me particularly but I can imagine, for example, an enemy that has most of its sprites in the Doom palette but, perhaps, the firing frames have a nice flash and so use a true colour frame for those graphics so that they can look prettier in GZDoom (I've done things like this myself). However, in ZDoom, if the sprite used colour index 127/R11G23B7 somewhere on it, the colour of the actor would change (albeit subtly) as it switched between the paletised images and the true colour ones.

It's not about the lookup table, per se. More accurately, truecolor to palette conversion operates in RGB555 colorspace and not RGB888 colorspace. This is small enough that it can be done using a 32k lookup table, and the whole conversion can be done just by lookup up each color in the table without much work. Plus, the lookup table was already there for blending effects, so it made sense to use it here too.

To use RGB888, a lookup table is prohibitively large. In a worst case scenario, using RGB888 is 256 times slower than RGB555, because it would need to scan every palette entry for every pixel in the image.

Just moving the description of the actual (suspected) bug to the new page.
[quote="Enjay"]...The bug is not that translations are messed up.

The real bug (as far as I'm concerned) is that ZDoom is incorrectly converting a colour in a true colour image when it is fitting it to the Doom palette. If a true colour image contains an area that is R11, G23, B7 (ie exactly the same colour as palette entry 127) when ZDoom converts the graphic to the Doom palette, it converts this area to R15, G23, B0 (palette entry 12).

...surely if an area in a true colour image is an exact match for one of the palette entries, that's what it should be mapped to when the graphic is shown in the game palette? I also think that it is reasonable for modders to expect that behaviour.[/quote]


[quote="albiongeck"]Perhaps there could a be settings entry for a more accurate lookup with increased performance hit?[/quote]
I don't know how expensive this would be processor-wise but perhaps if it is just for a handful of palette entries, then they could specifically be checked for. e.g. as far as I know, R11, G23, B7 is the only colour in the Doom palette that shows this problem (though I haven't checked thoroughly). Perhaps an "is the colour R11, G23, B7, if so map to 127, if not do the 15-bit lookup instead" check might not be too problematic? For all I know, a similar check for all the 256 colours in the palette may not be too expensive. Perhaps an "is this pixel one of the following 256 colours" check before the 15-bit lookup might be suitable?

Perhaps there could a be settings entry for a more accurate lookup with increased performance hit?

Although I mentioned translations in the initial report, I have since corrected myself. The bug is not that translations are messed up. I understand that them not working with true colour images is expected behaviour. Fair enough.

The real bug (as far as I'm concerned) is that ZDoom is incorrectly converting a colour in a true colour image when it is fitting it to the Doom palette. If a true colour image contains an area that is R11, G23, B7 (ie exactly the same colour as palette entry 127) when ZDoom converts the graphic to the Doom palette, it converts this area to R15, G23, B0 (palette entry 12).

Blzut3 explained where the error probably comes from (the 15-bit lookup) but surely if an area in a true colour image is an exact match for one of the palette entries, that's what it should be mapped to when the graphic is shown in the game palette? I also think that it is reasonable for modders to expect that behaviour.

And before anyone asks, no, it can't be fixed. Translations are not supported for any image that come with their own palette. If all used colors in the image's palette are unique in the game palette it *may* work, but only as long as you don't change the PLAYPAL.

The reason for the difference is ZDoom uses a 15-bit lookup table for palette matching. This is done for speed and the end result is usually accurate, but as you can see it can be slightly off.

[quote="Enjay"]I don't know how useful that would be versus saving the image in the Doom (etc) palette in the first place.[/quote]
I was about to say that it would allow you to utilize the untranslated version in true-color still, but that would literally be impossible if it's pre-palletized to begin with. Doh! Scratch that idea. :P

I don't know how useful that would be versus saving the image in the Doom (etc) palette in the first place.

Either way, I think the crux of this particular reported issue is nothing to do with translations (which, in retrospect, is only relevant because the colour being missed out of the translation made the error obvious to me) is that a colour that is actually in the Doom palette is being changed to a different colour in the palette when the image is displayed in Doom. Surely a pixel in a colour that is a 100% match with one in the game palette should be shown in its own colour rather than being interpreted as a different palette entry?

I wonder if it would be worth feature-requesting some way to specifically tell the engine to pre-palettize certain images upon load time, but I say this without knowing how much effort it would take. I can imagine it would get a fair amount of use since I seem to run into a lot of cases of "I'd love to use PNG here but can't because of translations", unless I'm mentally skewing things. Which is always likely. ;)

Then again, this may not be that great of an idea anyway because it would kill cross-game compatibility, which can still be faked to some degree by using a paletted original image and pairing it with a saturation translation (the latest build of Psychic does this with Bloodmoney and elemental casting effects). Pre-palettizing would ensure that the desired color range to translate would map to different indices per-game, unless you could specify exactly what palette to pre-palettize [i]to[/i]... hrm.

Mountains upon mountains of suggestions, of course. :P