ZDoom

[url=https://github.com/coelckers/gzdoom/commit/cfc080e37fe99fcdda70792a265ad6792d6fc33f]fixed[/url] (at least the issue in the OP - the issue later in this thread is completely separate and needs a new thread)

Yeah, i should have said they are gone reverting that commit bad choice of words. But then i thought in LZDoom gl_fuzztype is 6 by default and not many of its users have a HDR monitor. Also thought that it was only an enhancement for HDR not based on any recent previous commits else i wouldn't have picked it, HDR had been supported for a long time without that. I'm still waiting for a better solution anyway but for now the bug is gone in LZDoom.

Yes, but the fact that you suggest reverting the commit as your first go-to is really just not something you should do. It should always be a last resort.

Of course, but is it actually that important? Before that commit was not in and HDR worked, i obviously don't have a HDR monitor and the issue is serious enough to revert the commit unless a better solution is provided. Someone with a HDR monitor could try to fix that enhancement.
I mean reverting the commit is only a possibility, the important part is that now we know where the problem is.

Again it is not that simple as a revert will also break the intent of that commit.

I've found it and without having to compile, it's fixed reverting this commit:
https://github.com/coelckers/gzdoom/commit/db4310ca6bb9cd2548686e116f2d3496921a24e8
BTW now Travis-CI is paid, so i won't be pushing much for now.

I don't know where the problem is, gzdoom-x64-g4.1pre-92-g5b6bae409 does not show the issue. It comes from the now deleted vulkan2 branch, it had several hundred commits and was active for several months. I could try to investigate it in the legacy branch as i saved the devbuilds in my hard drive, it's something i cherry-picked.
Edit: nope, they are not old enough. 3.8.1_legacy is not affected, 3.8.2_legacy is.

Houston, we've got a problem. I've checked GZDoom 3.3.2 with a renamed LZDoom ini and it's not affected. The artifacts are very noticeable @1366x768. I backported some shader related stuff i think.
Edit: it's something recent, 4.1.3 was affected and 4.0.0 was not.
Edit2: [s]the problem is not in the shaders themselves, it's something related to the timer.[/s] BTW the dots appear near the monsters.

Hmm. Now that I've tested it on my laptop, the results are somewhat different, but only slightly. I have an RTX 2080 Ti on desktop and GTX 1050 Ti on laptop. I have updated the drivers to the latest version (as of now, that is 457.30). Tested with both Vulkan and OpenGL backends, there seem to be no difference between them (on the same machine, anyway).

Here's what I've found out:

[list=1][*]With gl_fuzztype set to either 3 (swirly fuzz) or 4 (translucent fuzz), the original glitch, as described in my first post from 2 years ago, only manifests with certain HUD weapon sprites - namely, the pistol, the super shotgun, and the chaingun. Other weapon sprites, as well as monster sprites, do not appear to be affected.
[*]With gl_fuzztype set to 6 (noise), the original glitch, as described in my first post from 2 years ago, still manifests with all HUD weapon sprites as well as monster sprites.
[*]With gl_fuzztype set to either 3 of 4, invisible monster sprites seem to display random white dots instead of white vertical lines. This behavior was reproduced both on my desktop PC and on my laptop. It appears, however, that the amount of dots is somewhat less on the laptop than on the desktop. Note that on both machines, GZDoom runs in the native Full HD (1920x1080) screen resolution.
[*]With gl_fuzztype set to either 3 of 4, weapon sprites display random white vertical lines, as described in my previous post, only on my desktop PC. I could not reproduce the vertical lines on my laptop.[/list]

diff --git a/src/gl/renderer/gl_renderstate.cpp b/src/gl/renderer/gl_renderstate.cpp
index 21da5f678a..0a4e4c4a9e 100644
--- a/src/gl/renderer/gl_renderstate.cpp
+++ b/src/gl/renderer/gl_renderstate.cpp
@@ -183,7 +183,7 @@ bool FRenderState::ApplyShader()
 	activeShader->muClipHeight.Set(mClipHeight);
 	activeShader->muClipHeightDirection.Set(mClipHeightDirection);
 	activeShader->muShadowmapFilter.Set(static_cast<int>(gl_shadowmap_filter));
-	activeShader->muTimer.Set((double)(screen->FrameTime - firstFrame) * (double)mShaderTimer / 1000.);
+	activeShader->muTimer.Set((double)(screen->FrameTime) * (double)mShaderTimer / 1000.);
 	activeShader->muAlphaThreshold.Set(mAlphaThreshold);
 	activeShader->muLightIndex.Set(mLightIndex);	// will always be -1 for now
 	activeShader->muClipSplit.Set(mClipSplit);

Seems this new report is a driver bug after all (or at least mine if it's not the same, i think i updated the AMD drivers recently), with this change the artifacts remain:
[code]diff --git a/src/gl/renderer/gl_renderstate.cpp b/src/gl/renderer/gl_renderstate.cpp
index 21da5f678a..0a4e4c4a9e 100644
--- a/src/gl/renderer/gl_renderstate.cpp
+++ b/src/gl/renderer/gl_renderstate.cpp
@@ -183,7 +183,7 @@ bool FRenderState::ApplyShader()
activeShader->muClipHeight.Set(mClipHeight);
activeShader->muClipHeightDirection.Set(mClipHeightDirection);
activeShader->muShadowmapFilter.Set(static_cast<int>(gl_shadowmap_filter));
- activeShader->muTimer.Set((double)(screen->FrameTime - firstFrame) * (double)mShaderTimer / 1000.);
+ activeShader->muTimer.Set((double)(screen->FrameTime) * (double)mShaderTimer / 1000.);
activeShader->muAlphaThreshold.Set(mAlphaThreshold);
activeShader->muLightIndex.Set(mLightIndex); // will always be -1 for now
activeShader->muClipSplit.Set(mClipSplit);
[/code]
@Player701: What's your graphics card? Do you see the artifacs i've mentioned?

I thought it was a driver bug and i didn't report that. Seems it's much worse, remember that the default gl_fuzztype is 0. LZDoom is also affected.
If i set gl_fuzztype to 4 for instance, summon a spectre and give myself the invisibility powerup i get glitches galore (lines and dots) as it walks around below me.
I get random glitches all the time while playing whenever i find a spectre.

Sorry for a two-year bump, just wanted to update this report with some new information.

[list=1][*]Still happens as of GZDoom 4.5.0 and development builds.
[*]The statement above saying that only the "Noise" fuzz style is affected is incorrect. "Swirly fuzz" and "Translucent fuzz" are affected as well.
[*]In addition to that, when fuzz style is set to "Swirly fuzz" or "Translucent fuzz", rendering artifacts in form of white vertical lines can be periodically observed even without loading a save file. Their appearance seems to be completely random. See screenshot below for details.[/list]

[imgur]https://imgur.com/ufyi8HH[/imgur]

With all these glitches, it doesn't look like an error in the shader function to me, especially considering that there are multiple shader functions that are affected.

It also happens only with the 'Noise' fuzz style. Looks like a bug in that shader function.

This issue happens with a very specific setup which depends on user settings as well as the game state, so I'm attaching my INI here to help reproduce the bug. Note that there may be other cases where this issue can manifest itself, but it all seems to happen when the level is loading.

Testing procedure:
[list=1]
[*]Warp to any map.
[*]Type "IDBEHOLDI" to get the blur sphere powerup.
[*]Save the game.
[*]Load the save. If "Screen wipe style" is set to "Crossfade", a rendering artifact will appear on the screen while the crossfade is happening. For me, it appears in the bottom area of the screen and looks like a thin black column spanning about 1/3 of the screen height.[/list]
Screenshot:
[imgur]https://imgur.com/wlVeE8T[/imgur]

Git bisect shows that the issue started happening in [url=https://github.com/coelckers/gzdoom/commit/ab32cb4c885605354c111ee573c4165945111cfd]this commit[/url].

System information: NVIDIA GTX 660, Windows 7 64-bit.