[Fixed] Weird dymanic light on walls

[_mental_]

It appeared that my attempt to fix compilation warnings (this line to be precise) revealed a problem with dynamic lights.
Here is a screenshot from The Crimson Deed.

Screenshot_TheCrimsonDeed_20181117_162803.jpg

To reproduce, use the following command line and rotate head to the left

Code: Select all • Expand view

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

I would revert my change but still how does this condition suppose to work? Before the "fix" it seems to function purely by occasion.

[Graf Zahl]

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?

[_mental_]

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

With unsigned index, i.e. before compilation warning fix, FLightBuffer::DoBindUBO() 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 index 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.

[Graf Zahl]

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?

[_mental_]

I reproduced exactly the same issue on Windows 10 with NVIDIA OpenGL 4.5 using -glversion 3 switch added to the command line from OP.
It was VS2017 x64 Release build at cc52f89 with the default config except 640x480 windowed mode.

[Enjay]

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: Select all • Expand view

**** 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

Dev build from 16 Dec.

No idea if that's related or not.

[_mental_]

To fix the glitch it's enough to move assignment of FLightBuffer::mLastMappedIndex from constructor to FLightBuffer::Clear() function.
Is this solution correct for render path with shader storage buffer?

[Graf Zahl]

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.

[_mental_]

Fixed in fb71563.