Visual glitch with desaturated sectors

[abbuw]

Using GZDoom-g3.3pre-563-g4b7e57b00-x64, bug appears to be introduced in GZDoom-g3.3pre-554-gc9613b2fd-x64. Appears to affect x32 builds too.

It appears that any sector with desaturation set has odd glitchy colours and static. In the map, the skybox and room both have desaturation values set. The room appears completely black when it should be fairly bright. The intensity of the static effect appears to be completely random, sometimes it's very strong, other times you have to fiddle a bit with freelook for it to show.

Map download link

[AFADoomer]

When I run the sample map, I get a much brighter and mis-colored version of the effect seen in this video.

This same effect occurs multiple times in Blade of Agony as well. If you want to see it there, just load map c2m1.



The effect does not happen with the 1 March dev build (449-gbc25ad413), but does with the 3 March dev build (554-gc9613b2fd) and later.

I believe that this coincides with the initial merging in of the materials branch... So there may be something in there that's the culprit.

[_mental_]

Works fine for me with integrated Intel and discrete NVIDIA graphics. What are the hardware and OS?

[Graf Zahl]

What are the hardware and OS?

This cannot be stressed enough. Reporting a visual bug without providing any more info is just like saying "The program does not work." It gives nothing to check. My guess is some incompatibility with older hardware, considering that this is about shader programming.

[AFADoomer]

I'm on Windows 10 (v1709) with integrated Intel chipset...

Code: Select all

GL_VENDOR: Intel
GL_RENDERER: Intel(R) HD Graphics 5500
GL_VERSION: 4.4.0 - Build 20.19.15.4531 (Core profile)
GL_SHADING_LANGUAGE_VERSION: 4.40 - Build 20.19.15.4531

I've also noticed similar (but much smaller) artifacts in the automap when looking at a sector that is affected by this bug (with textured automap turned on).

[abbuw]

I'm also on the same version of Windows 10 (v1709, Build 16299.248). My laptop has an Intel i5-5200U with an integrated Intel HD Graphics 5500. Just upgraded the graphic drivers today.

Code: Select all

GL_VENDOR: Intel
GL_RENDERER: Intel(R) HD Graphics 5500
GL_VERSION: 4.4.0 - Build 20.19.15.4835 (Core profile)
GL_SHADING_LANGUAGE_VERSION: 4.40 - Build 20.19.15.4835

[dpJudas]

I'm not seeing this problem on my MacBook Pro's Intel iGPU. It reports 4.1.0 for the GL version, though.

The only other Intel GPU I have is the one on my i7 Haswell. The i5-5200U is Broadwell, the generation after. I'll try unplug my Nvidia GPU and enable the integrated one tomorrow.

[_mental_]

Could it be related to particular combination of settings? Does it happen using the default configuration, i.e. without .ini file?

[Graf Zahl]

Just a quick note: This is the last remaining open issue I'd like to see resolved before starting to prepare a new release.
So it'd be great if this could be investigated quickly. On my system I cannot reproduce it, and my CPU is a bit too old to use the integrated chipset for any relevant testing - it contains a HD4000 which is barely GL 4.0 compatible (and too slow for real use.)

[dpJudas]

I've managed to reproduce the bug on my Intel HD 4600:



Looking into it now.

[dpJudas]

I've identified the code that causes the shader to break, but it makes no sense to me. It's this block:

Code: Select all

vec4 desaturate(vec4 texel)
{
	if (uDesaturationFactor > 0.0)
	{
		float gray = (texel.r * 0.3 + texel.g * 0.56 + texel.b * 0.14);	
		return mix (texel, vec4(gray,gray,gray,texel.a), uDesaturationFactor);
	}
	else
	{
		return texel;
	}
}

The mix statement there causes it to completely mess up the colors. The odd thing is that if uDesaturationFactor is set to 0 then it works fine, but any other value and it produces strange colors. If I return either texel or vec4(gray,gray,gray,texel.a) directly then it also works just fine.

By the way, is it normal/intended that it boots up in the compatibility profile for Intel?

[Graf Zahl]

No, and if you look at the posts above, it didn't do there.

So, regarding the messed up colors, if 'mix' is broken on Intel I guess some conditional compilation is in order that writes out the operation explicitly.
What's odd is that this didn't happen before, that code is quite old. Or did you change anything about the uniform being used in there?

[dpJudas]

I didn't change anything, except slightly rearranging how it calculates the attenuation. I tried rewriting that mix code in two different ways with the same visual glitch. I suspect the problem might be the light lists. Either they have some invalid data in them that only Intel couldn't handle, or my minor adjustment of how it looks up in the array broke the Intel GLSL compiler.

Going to try change the light lookup back into the way it looked before to see if that's the source of the problem.

[dpJudas]

Pushed a fix for this. For some reason it couldn't handle my branching for when there weren't any dynamic lights. Very odd.

[Graf Zahl]

Sadly, compiler bugs with GLSL are still an issue.