Odd palette problem in PrBoom+

Early on into Supplice's development, I ran into an odd problem in PrBoom+. One of the yellows in our new yellow range would constantly show up as a grey pixel (or some other color) in PrBoom+ but not in any other ports.

http://mekworx.the-powerhouse.net/mekastuff/wads/supppub/prboom+_suppal.bmp

Below are shots of the same areas in other ports.
WinMBF
Eternity
ZDoom

I got really frustrated because I couldn't figure out what was causing it, so I tried to get around it by replacing all instances of that particular color with another yellow close in color to it.

But after doing some more digging, I eventually found out that the color in question resides in palette index 255. I searched around and it seemed like it might be possible that a color in that spot might cause issues. Although this is not the case in other ports, including WinMBF where I figured it would cause a problem.

So does anyone know if this is a bug with PrBoom+? Or maybe it's a bug on our end?

Looking an PrBoom code (not PrBoom+, but it almost certainly inherits this) -- it seems that the new texture composition code (in r_patch.c) uses color 255 as the "nothing here" value when composing textures out of patches, and when it detects a "hole" (an existing 255 value) it copies the solid pixel to the left.

Judging by your screenshot that is exactly what is happening here.

There is probably no work-around to this behavior -- that code in PrBoom(+) would need to be rewritten to treat color 255 as a usable color.

Thanks for explaining what's going on here andrewj. I'm a little surprised that this is the behavior for PrBoom+. Well, from the sounds of it, it isn't a bug anyways.

Hmm, well I suppose this would be a good feature request for PrBoom+ then.

Thanks again :)

ZDoom has kind of the same system internally (turn one color index into a transparent color), but first it analyzes the palette to find a duplicate color and then does palette remapping of all images as they are loaded to avoid this issue.