DRD Team

Here's a repost of the bug, in simpler terms, easy to understand, no fuss, etc etc etc etc...

When translating a translated TEXTURES lump, ZDoom does so correctly and remaps the corresponding values.

However, GZDoom does not. GZDoom, instead, leaves the previous translation in place.

What I've done here, with test.pk3, is created a TEXTURES lump that makes the player sprite blue, using a direct palette remap.

Then with DECORATE, I created a TestActor that takes the exact translation and puts it back the way it was originally. This is the point where GZDoom and ZDoom differ - GZDoom (in GL) doesn't handle the translation the way ZDoom does.

As for the "shit you didn't want to wade through", Torr mostly wanted to know your actual stance on this more than anything. It's an issue for Skulltag because this method is used for one of the flags in a mod you'll obviously never care about or play.

Spoiler: Thar be screenshots here!

---

test2.pk3 - summon TestActor
ZDoom / Software

software.png (217.54 KiB) Viewed 521 times

test2.pk3 - summon TestActor
GZDoom

gzdoom.png (258.02 KiB) Viewed 521 times

And here's a test wad...

This working in ZDoom is undefined behavior. I'm sorry but with true color graphics composition it's not fixable. It also won't work if you try to create a true color image for 2D display in ZDoom.

If this ever worked in older versions of GZDoom it was probably caused by incorrect conversion from paletted to true color in the texture composition code which used the complete 8-bit path for compositing the texture. But that can't be done because translations are not necessarily palette bound. It would cause bugs elsewhere.

The bottom line is: You may only use translations on original graphics that actually use PLAYPAL. For everything else, even PNGs containing the exact palette proper operations are not guaranteed.


It's a clear case of 'Don't do that!'.

I'll let them know, then. (and closed, hope you don't mind)