Black sprites = ice too light?

Sat Feb 06, 2021 3:47 pm

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:
Image

ends up looking like this when he is frozen:
Image

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.

Re: Black sprites = ice too light?

Sat Feb 06, 2021 4:00 pm

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

Re: Black sprites = ice too light?

Sat Feb 06, 2021 4:12 pm

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.

Re: Black sprites = ice too light?

Sat Feb 06, 2021 4:32 pm

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.

Re: Black sprites = ice too light?

Sat Feb 06, 2021 4:41 pm

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?

Re: Black sprites = ice too light?

Sat Feb 06, 2021 5:28 pm

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.

Re: Black sprites = ice too light?

Sat Feb 06, 2021 5:35 pm

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?

Re: Black sprites = ice too light?

Sat Feb 06, 2021 5:50 pm

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"