ZDoom

That's the only thing that makes sense. It feels way too hand-holdy to me, though, but hey I wasn't the one who designed them.

I would've done it so that a red subtractive light results in a proper cyan blob from the source.

[quote="Rachael"]I think you can, dpJudas. But remember one thing about subtractive lights:

No matter what colour they are, their hue is flipped 180 degrees. I don't know the exact design decisions behind that[/quote]

I think Timmie did it so that the effect it generates corresponds to the given color, i.e. make a red subtractive light and you get a red shadow.

I think you can, dpJudas. But remember one thing about subtractive lights:

No matter what colour they are, their hue is flipped 180 degrees. I don't know the exact design decisions behind that, it actually kind of frustrates me, but that is what it is. So a subtractive light of (255,0,0) actually renders as (0,255,255) in the engine. I can give some quicky math formulae if you need to preserve the luminosity and saturation values while flipping the hues, without actually breaking the colours down into HSV values.

Makes sense. I wonder if I could get away with desaturating the light color when building the light list for the drawer. And thinking about it, maybe I can support subtractive lights by making the light color a negative value.

I don't think that handling additive lights is necessary. But subtractive lights are better skipped entirely instead of rendering them additively - that only increases the perception of faulty behavior.

Regarding the desaturation that has been mentioned - that is related to the sector color desaturation feature. To make lights look right it also needs to apply to the light being emitted by objects whose color got desaturated. Having a grayed version of a BFG projectile emit bright green light just looks wrong.

Hmm, maybe that should be a toggle-able option to enable/disable having additive/subtractive lights. I agree about how they look, though; The software renderer's idea of "fog" and how the lights look are totally different than the OpenGL renderer.

[s]Maybe the fog should be altered for consistency too but this isn't a feature request thread, this is a bug report.[/s]

This is a known limitation of the software renderer. It is technically trivial to fix, but I fear it will produce a measurable performance drop in doing so. At least it would require a second set of drawers to prevent that.

For what it is worth, I'm not even sure if the software lights are "normal" or "additive" compared to what the GL renderer does. There seems to be some kind of desaturation involved with normal dynlights, if I read the shader code right. The software renderer does not do that.

I noticed when going through my levels of my TC today that my second level, a city at nighttime, appeared to be bright instead of the buildings fading out into the darkness below. I went there again and it was fine...I then started suspecting the software render may be rendering the wrong type of light and saw that was what was happening.

I made a test map that has one of each light and saw it was worse than I thought; Normal, additive, and subtractive lights are all rendered as normal dynamic lights in the software renderer!
[attachment=2]software.jpg[/attachment][attachment=1]opengl.jpg[/attachment]
Here's the test WAD.
[attachment=0]test_badlights.wad[/attachment]