Black sprites = ice too light?

[Enjay]

Clumsy title, and possibly not even a bug either. Applies to all renderers.

If a sprite has any pixels that are 0,0,0 in colour and the actor using those sprites suffers an ice death, the black pixels get translated to a colour that, in my opinion, is too bright.

e.g. this guy:


ends up looking like this when he is frozen:


His trousers, clipboard, edge of his shoes and hair have become very light in colour and it gives the sprite an awkward semi-negative-colour kind of effect.

I'm not convinced it was always like this - but I'm also not convinced that it wasn't.

Would there be any way to ensure that true black areas explicitly get translated to something suitably dark but still consistent with the icy palette? I know that true black isn't a good choice for sprites anyway, but sprites with black areas are out there.

[drfrag]

May be it's a bug, why don't you try it with LZDoom 3.87c?

[Graf Zahl]

Trying to translate color 0 is a bit problematic thanks to some ancient implementation issues. The translation code is at odds with the internal color remapping that is being done here. Unfortunately this is something I cannot fix easily as the entire paletted part of the texture management was hardwired to treat color 0 as transparent.

[Enjay]

Actually, I apologise, this was observed with a custom playpal. It does not seem to happen when the standard Doom playpal is loaded. I'll need to dig a bit more though because the PLAYPAL in question isn't particularly dramatic and is really just a slight shift in some of the often edited Doom colour ranges.

I'll report back.

[Enjay]

OK, interesting, in the custom palette, entry 247 had been changed to 0,0,1 making it very dark blue instead of true black (fair enough, it's right at the end of the blue range in the palette order).

So, what I am guessing was going on here was that the PNG sprite (which has its own palette) was being mapped to the internal palette at some point in the translation process and with the only 0,0,0 entry in the palette being #0 it got mapped there and that's the one with the special handling. On changing entry 247 back to 0,0,0 the problem goes away, so I'm guessing, under those circumstances, the black pixels get mapped to entry 247 and it has different handling for the translation?

[Graf Zahl]

What this does when the exact color is not found is to find a duplicate in the palette and do a double remap. And that's the case where translations will break for real because this case was never considered and the data wasn't abstracted well enough. So, when the translation gets applied the remapping was already done.

[Enjay]

Understood, thanks.

It sounds like you don't need any more information but do you want me to throw together a quick test file? Or perhaps this is going to be a [Won't change] anyway?

[Graf Zahl]

If I had had an idea how to deal with this, the texture management would deal with this, so for now it's indeed "won'r change"