[g4.4pre-273>] Translation/Palette Issues

[Lord Misfit]

So after a large jump in SVN revisions to g4.4pre-281 [the first version I could run, since 273 wasn't appearantly loading server CVars and I was having issues on that one], I eventually came to notice that when I went into Chasecam mode, my main playerclass in Aetherius would have her sprites look like they were being run through some kind of 256-color translation/palette, despite the fact in versions before, her sprites displayed properly as full-colored.

I also then did comparisons with the other playerclasses, and I also noticed the palettes were off with them. The screenshots below show the comparisons with the palette in g4.4pre-137 on the top [the last SVN before there was a big mass of updates including whatever probably caused this change/bug with palettes], and g4.4pre-273 and later on the bottom half of the screenshots. I also have a debug thing running that shows the "translation" #. The main player class [third screenshot] has "65536" in both, which I guess is meant to represent a non-existant translation, while the other two player classes [first two screenshots] have a different translation # from her, but it remains the same number on both SVNs in the comparisons.

[imgur]https://i.imgur.com/U15Hbo4[/imgur]
[imgur]https://i.imgur.com/XVCgWKM[/imgur]
[imgur]https://i.imgur.com/Hw2Yov8[/imgur]

Now for the other two characters [aka the Marine-type players in the top two screenshots], the mod has a mechanic where their translations/palettes change to visually reflect what armor class they're wearing. From what I could tell, when they got higher armor classes, palettes I'd recognize began to show on them, but they still weren't the "correct ones", as if the translation ID table actually being used in-game was shifted back by 2. For the record, I defined these Translations initially in ACS, and use "Thing_SetTranslation" to set the player-actor with these translations when you're using the other two marine classes.

Still, this doesn't explain why the main playerclass, who doesn't have any dynamic changes to her palette/translation occur in gameplay, still has a sort of palette that makes her sprites 256-colored in these recent SVNs.

I'm not really privy to what kinds of changes where made in these 135+ revisions to the engine, though I did notice stuff related to the palette/transations were changed or altered in some of the commit explanations.

I have tried messing with renderer options, though I admit I don't know if I've tried every possible option. I also don't know exactly yet how else I could help in making this issue easy to address. Not sure if I should try to break this down into a seperate file from the Aetherius mod. If you can get the base Aetherius mod, all you have to really do to see this in action [as far as I can tell] is to load the mod, using the chasecam cmd and look at the player's sprites in the SVN #s mentioned above for comparison. Again, if you want me to try to make a smaller sample, lemme know, but I wanted to at least bring this to attention before I make my next step to help get the issue fixed, in case it's a simpler case to fix it than I thought. x.x

[Lord Misfit]

An update on this. I should mention I'm on "OpenGL", using the "Hardware Accelerated" option for the conditions of the post above.

However, I just found out that regarding the main player class [the true-color sprites]. I noticed if I set the Render style to "True Color SW Render", her sprites go back to full color again, but only when that option is selected. I have not tried this with Vulkan or the other Rendering APIs yet.

However this doesn't do anything about the weird palette/translation issues for the other two player classes. They still look weird in the same way on 4.4pre-273> even using "True Color SW Render", so it might be possible the issue there is a seperate one from the issue with the mod's main player class and the supposed-to-be-full-color sprites they use.

I wonder if the translation table is off/shifted incorrectly for the other two player classes' sprites, while there's some still-unknown other issue with the main player class and why they're not showing as full-color.

[Graf Zahl]

Any links to testing material?

[Lord Misfit]

https://github.com/LordMisfit/DV-DS-ComboPack/ - the mod itself is here. And as I said before, all you really should need to do to test this is to load the mod, pick each character class and load into MAP01 or E1M1, use "chase" to show chasecam mode, and view the differences in their sprite's palettes/translations and colors in both g4.4pre-137 [where they were still working right] and any version from g4.4pre-273 and on so far. If there had been appveyor versions, I'd have tried to go though that large set of commits to find when the first one that had had the issue had come up, but appearantly appveyor builds are no longer a thing. -_-;

Now I'll TRY to see if I can get a more compressed example for download later on if you need it, but I can't say to how quickly I'll be able to do it, since there appear to be two issues related to this big set of commits, the one for some full-color sprites being set to 256-colors, and the one where it seems the translation # tables could be off between the commits, and I'm not sure if you'd want me to isolate both issues into their own mini seperate downloads, or if I should keep them both together in a smaller sample. o.o

EDIT: Been making that smaller sample for you to look at in the meantime. It's not ready just yet, but I will mentioned the issue with the full-color sprites for the playerclass I mentioned above is also already showing up in this if you run with 4.4pre-237>. I still need to get some means to get the translation issues for the other player classes replicated. :V

[Lord Misfit]

https://drive.google.com/file/d/17uEkRj ... sp=sharing - file for testing

Okay, now I think I got things recreated with the translation effects too. If you choose Illucia or Deggaris as the player class, it'll cycle through the five translations used to represent their armor classes on their player sprites automatically every second with a message stating the translation #id used.

This also has Flora [the main player class who has the normally full-color sprites] selectable too, so you can check this. Her palettes are not set to change.

But make sure to run these in both 4.4pre137 and then any current SVN at or past 4.4pre-273 to compare the differences. I'm sorry I have no other ideas as to what could be wrong, but I was able to make a compressed example that hopefully should work. To also remind you, I am using OpenGL with Hardware Acceleration [though Flora's sprites still appear full color IF you use "SW True Color Render", but only that, for whatever reason.]

[Graf Zahl]

The general problem here is that you used PNGs - the actual color mapping from PNG to palette is not well defined and subject to changes of the color lookup algorithm. And it looks like this was changed since you created your sprites. This applies even more to true color sprites as yours seem to be. Sorry, can't fix this. Locking the color lookup algorithm would mean we can't use a better one if more modern hardware allows to do so.

For the player classes that are supposed to be translated, you should store them in Doom patch format, not PNG - and for your player class that's not supposed to be translated, you *must* use the +DONTTRANSLATE flag to avoid unwanted translation artifacts.