ZDoom

Fixed in [url=https://github.com/coelckers/gzdoom/commit/fb7156331136754683fdbe2de825b88d067de067]fb71563[/url].

Yes, that should be fine. It looks like it is losing the binding each new frame somewhere else. Curse OpenGL's global state system where anything can stomp on everybody else's data and leave a mess behind.

To fix the glitch it's enough to move assignment of [url=https://github.com/coelckers/gzdoom/blob/2ce91ea62f505cc71949260533d0c221afacb2e3/src/hwrenderer/dynlights/hw_lightbuffer.cpp#L67]FLightBuffer::mLastMappedIndex[/url] from constructor to [url=https://github.com/coelckers/gzdoom/blob/2ce91ea62f505cc71949260533d0c221afacb2e3/src/hwrenderer/dynlights/hw_lightbuffer.cpp#L78]FLightBuffer::Clear()[/url] function.
Is this solution correct for render path with shader storage buffer?

**** DIED WITH FATAL ERROR:
Unable to load shader parallax:
Init Shader 'parallax':
Fragment shader:
0(72) : error C1059: non constant expression in initialization

Linking:
Fragment info
-------------
0(72) : error C1059: non constant expression in initialization
(0) : error C2003: incompatible options for link

I don't see the error on my setup using default settings. However, if I use -glversion 3 I can't even get it to start.

[code]**** DIED WITH FATAL ERROR:
Unable to load shader parallax:
Init Shader 'parallax':
Fragment shader:
0(72) : error C1059: non constant expression in initialization

Linking:
Fragment info
-------------
0(72) : error C1059: non constant expression in initialization
(0) : error C2003: incompatible options for link[/code]
Dev build from 16 Dec.

No idea if that's related or not.

I reproduced exactly the same issue on Windows 10 with NVIDIA OpenGL 4.5 using [b]-glversion 3[/b] switch added to the command line from OP.
It was VS2017 x64 Release build at [url=https://github.com/coelckers/gzdoom/commit/cc52f893728b0b4eedacda7cf6ef26cc3618c3bc]cc52f89[/url] with the default config except 640x480 windowed mode.

This function must be called on systems not using shader storage, because the UBO window is only 64 kb, but the light buffer can be larger.
But I have to admit that this case hasn't been thoroughly tested because it's a legacy fallback and for modern hardware never becomes an issue.

Oh yeah, and welcome to the land of undefined language behavior. Don't you just love the C++ committee and their refusal to have a robustly defined language?

I tested on macOS with Intel and NVIDIA graphics. Although, I don't think it's related to hardware at all.

With unsigned [b]index[/b], i.e. before compilation warning fix, [url=https://github.com/coelckers/gzdoom/blob/c92e6b03ac461ac16c13412ae414332145e60081/src/hwrenderer/dynlights/hw_lightbuffer.h#L53]FLightBuffer::DoBindUBO()[/url] is never called. This means no glitch.
Apparently, 2^32-1 is greater than -1. Probably, different compilers can handle such comparison differently.
With signed [b]index[/b] the mentioned function is called several times per frame. The glitch is now visible.

That's why I was asking how this is suppose to work.

That location looks fine to me - with your fix active, no matter whether I use -glversion 3 or not.

What hardware/driver did this happen on?

-iwad Crimson_Beta_V2.ipk3 +map vmp02 -nomonsters +warp 10 430

It appeared that [url=https://github.com/coelckers/gzdoom/commit/504a7f00b69da06fed8c9c521ffa5fbfda75960a]my attempt[/url] to fix compilation warnings ([url=https://github.com/coelckers/gzdoom/blob/160f17a90772cfb340c55b91365b21a8c226384f/src/hwrenderer/dynlights/hw_lightbuffer.h#L49]this line[/url] to be precise) revealed a problem with dynamic lights.
Here is a screenshot from [url=https://forum.zdoom.org/viewtopic.php?f=19&t=62152]The Crimson Deed[/url].

[attachment=0]Screenshot_TheCrimsonDeed_20181117_162803.jpg[/attachment]
To reproduce, use the following command line and rotate head to the left[code]-iwad Crimson_Beta_V2.ipk3 +map vmp02 -nomonsters +warp 10 430[/code]
I would revert my change but still how does this condition suppose to work? Before the "fix" it seems to function purely by occasion.