textures lump translation, color shift

Moderator: GZDoom Developers

Forum rules
Please construct and post a simple demo whenever possible for all bug reports. Please provide links to everything.

If you can include a wad demonstrating the problem, please do so. Bug reports that include fully-constructed demos have a much better chance of being investigated in a timely manner than those that don't.

Please make a new topic for every bug. Don't combine multiple bugs into a single topic. Thanks!
User avatar
simc
Posts: 131
Joined: Fri Feb 03, 2012 11:44 am

textures lump translation, color shift

Post by simc »

Some Doom palette texture colors get always slightly changed in sw/non-true color if at least one of the texture's patches in textures lump has a translation string. That's when the color and the patch themselves aren't translated.

This came in between GZDoom-g3.3pre-623-gd83456e9c (March 13 2018) and 3.3.0 (March 25 2018). Doesn't happen in hw accelerated or sw/true color.

Here's a screenshot of three 64-wide comp textures side by side. They all should be identical.
https://i.imgur.com/y1WTlvw.png

On the left is the original (Doom patch COMP04_7) with no translation.

In the middle, it has two red colors changed to blue: Translation "176:177=192:193". No such colors appear but the gray (#110) is changed to a darker tone. Other colors are as in the original.

On the right, it has every color translated back to itself: Translation "0:255=0:255". There should be no changes but the gray (#110) is a darker again.

Textures:
Spoiler:
This happens to certain colors only. (16? colors in total) It's well notable with the mid-gray tones such as in COMPSPAN. It looks that:

#104 (79, 79, 79) turns to (75, 75, 75) (same as #3)
#107 (59, 59, 59) turns to (55, 55, 55) (same as #108)
#110 (39, 39, 39) turns to (35, 35, 35) (asme as #111)

But for example #3, 96-103, 105, 106, 108, 109, 111 aren't changed.

-------------------------------------------------------------------------
Edit: The changing colors:

#7 (11, 11, 11) -> #8 (7, 7, 7)
#13 (79, 59, 43) -> #236 (79, 59, 39)
#30 (167, 63, 63) -> #31 (163, 59, 59)
#32 (155, 51, 51) -> #33 (151, 47, 47)
#36 (131, 31, 31) -> #37 (127, 27, 27)
#38 (119, 23, 23) -> #39 (115, 19, 19)
#40 (107, 15, 15) -> #41 (103, 11, 11)
#104 (79, 79, 79) -> #3 (75, 75, 75)
#107 (59, 59, 59) -> #108 (55, 55, 55)
#110 (39, 39, 39) -> #111 (35, 35, 35)
#142 (87, 67, 51) -> #143 (83, 63, 47)
#143 (83, 63, 47) -> #13 (79, 59, 43)
#144 (67, 51, 27) -> #77 (63, 47, 23)
#236 (79, 59, 39) -> #150 (79, 59, 35)
#237 (67, 47, 27) -> #15 (63, 43, 27)
#255 (167, 107, 107) -> #133 (155, 127, 107)
You do not have the required permissions to view the files attached to this post.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49140
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: textures lump translation, color shift

Post by Graf Zahl »

This is because texture composition with non-trivial patches is done in true color and then downconverted back to the palette, and that can result in up to 2 bits of loss of color precision.

Return to “Classic ("Carmack") Software Renderer Bugs”