PRBoom Plus/DSDA Doom ignores custom radiation suit palette colour in OpenGL mode

[Arsinikk]

In the current wad project I am working on, I have a custom palette that includes a purple overlay instead of the default green overlay when the radiation suit is picked up.

This seemed to work correctly with the majority of ports including Vanilla Doom, Chocolate Doom, Eternity Engine, Crispy Doom, Woof, etc.

 

GZDoom did not work correctly, however I was able to include a DECORATE lump to specify the custom overlay color.

 

PRBoom Plus and DSDA Doom do in fact use the correct palette only in the software renderer.

In the OpenGL renderer, however the radiation suit color does not change from the default green.

 

Does anyone have any ideas/thoughts on how to get the custom radiation suit color to work in PRBoom Plus/DSDA Doom's OpenGL mode?

 

Edit: this video was recorded using the latest PRBoom Plus 2.6.1um showing the difference:

 

Edited September 17, 2021 by Arsinikk
Added visual example and specified PrBoom version.

[Graf Zahl]

Hardware rendering does not use these palettes (doing so would necessitate creating new textures for every single one if these layers of intensity which is utterly prohibitive), it draws a translucent solid colored rectangle over the entire screen, and no port so far has any logic to extract this blending color from the provided PLAYPAL.

[Arsinikk]

Ah, so the the OpenGL rendering does not rely at all on the vanilla palette?

Instead the translucent colours are hardcoded into the port itself...

 

Too bad there's no way to replace a resource or colour value that could be declared in prboom-plus.wad...

 

That way the logic wouldn't have to change, but the value could be changed via replacing a lump by a modder.

[Gez]

2 minutes ago, Arsinikk said:

Ah, so the the OpenGL rendering does not rely at all on the vanilla palette?

There's 14 palettes in PLAYPAL, only the first is used.

 

21 minutes ago, Graf Zahl said:

and no port so far has any logic to extract this blending color from the provided PLAYPAL.

A simple approach would be to look for the white index in the base palette, and then look at the color of this index in the other palettes.

[Arsinikk]

12 minutes ago, Gez said:

There's 14 palettes in PLAYPAL, only the first is used.

 

Oops, my bad. Obviously if the first palette wasn't being used, the main palette wouldn't change. Thanks for clarification.

[Graf Zahl]

24 minutes ago, Gez said:

A simple approach would be to look for the white index in the base palette, and then look at the color of this index in the other palettes.

 

To guesstimate a translucency value you need to check black and white, like ZDoom implemented for TRANMAP.

This of course only works as intended if the palette is not being inverted so for invulnerability it'd be unable to determine the proper blend mode.

 

[QuotePilgrim]

14 hours ago, Gez said:

There's 14 palettes in PLAYPAL, only the first is used.

Maybe for DOOM format graphics that's the case, as the palette and graphics are separate. But for PNG images (or other formats a port might support), with hardware rendering it's going to completely ignore PLAYPAL and use whatever colors are in the images themselves.

[Arsinikk]

35 minutes ago, QuotePilgrim said:

Maybe for DOOM format graphics that's the case, as the palette and graphics are separate. But for PNG images (or other formats a port might support), with hardware rendering it's going to completely ignore PLAYPAL and use whatever colors are in the images themselves.

While technically true about PNG images, for a Vanilla compatible project this is a bit irrelevant being that Vanilla does not support PNGs in the first place.

 

I was just looking for a way to keep the wad experience consistent between sourceports.

 

But if all else fails, I guess I could just ask people to only play the wad in the software renderer in PrBoom Plus/DSDA Doom. After all, the performance shouldn't suffer much being Vanilla Compatible.