[G1.9pre-738-g1f0c69a] Minor dynlight issue

[hetdegon]

Hello again. I have kept following the glew_version_for_real branch for a while (master still has the older glitches I reported until both branches get merged).
Everything is working really smoothly actually, except there is a very minor bug regarding dynamic lighting. Took me ages to take a screenshot of it because it happens only for a split second.
Here is an unmodded (except for brightmaps, but I have verified the glitch happens without them as well, so we can rule that out) E1M2 screenshot.
<EDIT> Removed due to clearer shots below.

This bug only happens in dark areas, whenever dynamic lights come from an enemy's attack. It doesn't happen all the time, but it's more noticeable in maps like E1M2 or The Crusher (starting area) of Doom2, where there are dark rooms with enemies that have dynlight definitions. Seems to happen only when two different lights mix in those dark sectors. It can also happen to the player's weapon but much more rarely.
Note that the bug happened for the first time in the previous commit, but I was unable to capture it in screenshot until now. Quite tricky!

[Graf Zahl]

What's your graphics card and settings, especially gl_dynlight_shader?

[hetdegon]

It's a nVidia GT630, and gl_dynlight_shader is false (I can't turn it on from the menu and resets if I set it from config. No errors or anything, it just doesn't move to "yes" if I try)
EDIT: I am able to reproduce it with the default config at the same spot. (./gzdoom -noautoload -iwad /home/storage/Games/Doom/IWAD/DOOM.WAD -file /home/storage/Games/Doom/GZDOOM/lights.pk3 -config /dev/shm/.test) (/dev/shm/.test being a non-existing file that gzdoom generates, not an existing config)

[hetdegon]

Sorry to doublepost, but I made a few tests about this bug. On the current git build G1.9pre-777-g9a6bc64. (Hey, jackpot)
Since reproducing it was pure, utter pain and you needed the planets to align for a zombieman and an imp to coordinate, I made this test map showing the light mixing.
https://dl.dropboxusercontent.com/u/95471203/test.wad
It uses 4 point lights. The RGB trio, and then a r=g=b=128 light. Note that the 3 RGB lights mix beautifully, it's when adding the fourth light that the glitch occurs. Shooting a plasma rifle or something with lights makes it turn into rainbow puke.
For quick reference, here are these screenshots, I'll remove the previous ones since these are clearer:



On the dynlight shader, there's something about it. Last time I tried, enabling dynlight shader from the config file didn't work, but now, it does and stays enabled, but I still cannot enable it from the menu if I try. Anyway, it's enabled now, all working properly on that regard (I assume it was using it anyway despite the variable being false?). The mixing glitch still happens, though. Let me know if you can reproduce it with that test wad.

[Graf Zahl]

The dynlight shader isn't in the menu because in older versions it was broken on AMD (thanks to a miscalculation with the max. amount of fragment uniforms) When that was fixed it was simply forgotten.

With your test WAD I get the glitch, too. I think it's an overflow in the calculations that add the lights for sprites.

[Graf Zahl]

Fixed. As expected it was an overflow. For the items in question one light channel became larger than 1.0 but was stored in a byte without clamping it to the valid range first.