DRD Team

Does LLVM have a debugger? Maybe you can compile them with that, and maybe it's possible at the very least see what the differences are in the shaders between GZDoom's initialization and QZDoom's - even if the LLVM shaders do not produce any errors.

At this point, though, I am just shooting out ideas. I'm just as clueless as you are what's causing this. NVidia has a pretty solid driver history compared to the other two, but it's not infallible and I've had quite a few botched NVidia drivers in the past.

Also - do try the rename exe trick - it's possible NVidia already accounted for this in GZDoom but failed to take QZDoom into consideration due to it being too new. That kind of fuckery certainly exists with ATI drivers and is quite common there.

Here's what I got so far:

1. It works in my local build of QZDoom, GZDoom, and the GZDoom ssao branch.
2. It does not work in the latest nightly build that I use when playing Doom (your builds got all the sound compiled in - mine is missing some of that).
3. It also does not work in a much older October build of the GZDoom ssao branch that I used to use for playing in the past.

Right now I'm betting on it being an issue with the nightly build somehow using files out of date. Is there a way to force a rebuild?

I'll clean my build tree. Were you going to do any work on the code base today? It would probably help a lot if the git hash number gets bumped, instead of me deleting and replacing the latest one. Actually - it seems like you made a commit after the latest build, so I'll just build that commit. New builds should be up somewhere between 20-40 minutes after this post.

Excellent. Thanks Eruanna. Hopefully this is the cause, because otherwise it has to be some oddity with differences between my ini files that triggers it one place but not the other.

I've tracked down what decides if it works or not: the texture filtering mode. If it is set to None then it works, if its set to None (Trilinear) it doesn't.

What is probably happening is that the sampler is in trilinear mode, which requires mipmap. It shouldn't matter as the tonemap GLSL uses texelFetch, which doesn't do any sampling. Either there's some rule deep down in OpenGL that says the texture must always be texture complete, even for texelFetch, and they just fixed that in their driver. Or they introduced a bug that makes texelFetch not work in a situation where it should.

Anyhow, I'll do some test a bit later whether GZDoom is affected by it, or just the SSAO branch. Then fix it by making sure that the sampler is set to nearest always for the tonemap texture, regardless of the setting in the menu.

dpJudas wrote:Anyhow, I'll do some test a bit later whether GZDoom is affected by it, or just the SSAO branch. Then fix it by making sure that the sampler is set to nearest always for the tonemap texture, regardless of the setting in the menu.

That should be done for any postprocessing anyway, if you do not have a mipmap complete texture, always choose a mode that doesn't use mipmaps, i.e. GL_NEAREST or GL_LINEAR, depending on what is needed. It really wouldn't surprise me if this causes other black screen issues as well. AFAIK the GL spec is very strict here: Use of a mipmap incomplete texture with such a mode is an error.

I have the texture filtering set to Trilinear and 16x anisotropic. The display output seems to come back when toggling the filter between Trilinear and None, and stays working until the next level load, at which point the screen turns black again.

Graf Zahl wrote:That should be done for any postprocessing anyway, if you do not have a mipmap complete texture, always choose a mode that doesn't use mipmaps, i.e. GL_NEAREST or GL_LINEAR, depending on what is needed. It really wouldn't surprise me if this causes other black screen issues as well. AFAIK the GL spec is very strict here: Use of a mipmap incomplete texture with such a mode is an error.

I agree, but somehow I must have forgotten to do that with the tonemap LUT texture. Since apparently all the vendors didn't check for this properly I never noticed.

So does this mean it is a GZDoom bug? If so, and if the forum allows, you can move it to the GZDoom forum.

Just fixed it. Should be working in the next build of QZDoom.

Turns out it was due to a regression in the SSAO branch made for GZDoom. The good news is that this hasn't been merged into GZDoom yet, so GZDoom is in the clear.