ZDoom

Thanks for the explanation!

Yes, that's the same issue. The True Color renderer cannot use the colormaps and has to use standard math to do it so you lose any special tweaking of the colormap.

I would like to ask a question regarding color reproduction in true color rendering since we touched the topic. Playing Heretic I selected OpenGL renderer and set light mode to "Software" to be as close to software mode as possible. When looking at certain textures like water or lava they are not as saturated as in 8bit renderer. Is this related to how true color render works?

Software 8bit:


OpenGL 32bit:

I agree when it comes to custom colourmaps like the Raven ones. With Doom's though it's just a nearest colour match, which is what you get when you palettize a LUT with the Doom palette.

You can emulate the palette with that but not the colormap. No, it's not the same.

If you set Tonemap Mode to Palette (gl_tonemap 5) you can emulate 8 bit in the OpenGL renderer. There's also my old Troo Cullers shader which smooths that out so you can have higher colour depth without losing the 8 bit look. Both options are better suited to Doom's colourmap though than anything else.

I'm just saying that it's nice to have an option to play in 3D and in 8bit colors.

The palette isn't the issue here. What you describe is the depth fading from the colormap. And since that is a per-pixel palette to palette lookup it is impossible to support in a true color renderer because it would negate its entire purpose.

The main benefit for me is that thanks to 8bit softpoly renderer I can play supported games using their original palettes and in full 3D. When using truecolor rendering some colors get dimmed, something that is especially visible in Heretic with it's vibrant colors. It's just isn't as pleasing to look at. Mods that use truecolor to it's fullest potential are another story. I don't know if you can force the original palette when using OpenGL renderer.

It surely can be fixed. The drawer for this has to be changed to handle full transparency. An alpha of 0 normally means not to touch the pixel at all.
But in the end this is really just the softpoly drawer and I have my doubts it will ever leave the experimental stage. From a usability standpoint it doesn't offer much of value because it is not only slower than the hardware renderer but also a lot lighter on features.

I don't know if this problem can be fixed.

What's happening here is the sprites are being drawn in a square. I would not have known it before, but it seems pretty obvious now - it's processing all pixels in that square, even if they're clear - which means that it's pushing them through the RGB666 table and the darkening is what's coming out the other side.

The real kicker is this: First, You have to up the gamma or brightness quite a bit to even see this effect. Second, this IS the 8-bit software renderer - even if it is softpoly. If you really need precise 8-bit colour drawing you can do "gl_tonemap 5" and swap to the truecolour softpoly instead.

In my opinion the only reason to even consider fixing this issue is if it would improve the speed of the softpoly drawers.

This is plain wad, no additional effects added. When you cycle through other renderers in the same playthrough the problem doesn't happen.

EDIT: I would to add that it doesn't happen in true color softpoly renderer either.

Is this plain Heretic or are you using some mod that replaces the puff? This effect can happen if a sprite uses additive translucency but doesn't properly define the parts that are fully translucent, leaving them black.

Transparent color in sprites appears as a dark box. You can see it when you turn up the brightness (i.e. to 2.0). There is no dark box in software or OpenGL renderes.

Tested in GZDoom 3.6.0.