by Lord Misfit » Fri Apr 17, 2020 9:57 am
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
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