Screen Melt Way Too Slow

[sinisterseed]

Ok. Can you try to track this down with devbuilds?
If you need older ones you need to enable developer mode

---

that option is hidden under "Change skin"

I have no problems here so I need help from someone who does experience this.

Hopefully, but won't be today, got busy in the other place and I'm tired now.

[sinisterseed]

I think I found the interval when this broke, and am now hunting down the build when this first surfaced.

It's somewhere between September 20th and September 29th, the build from 20th works fine in GL.

[sinisterseed]

Found it. Ding dong, the bitch is dead .

It originally surfaced in the September 28th build, gcd20ecaae - https://devbuilds.drdteam.org/gzdoom/gz ... 20ecaae.7z .

The Sep 27th build doesn't even work, actually. It crashes at startup.

[Rachael]

Thank you, that helps a lot. Might need to test builds between those two.

Unfortunately, that is the day of a ton of Raze updates and lots of work was done that day.

[Graf Zahl]

I suspect the change to the texture sampler system. That looks like the only one which alters the renderer's internals. It may be that the melting code does not play nicely with it.

[Starisma1]

So I wonder will this bug be fixed in 4.5?

[Graf Zahl]

If we find it, yes. Since I cannot reproduce it on my hardware I have to wait for others to narrow it down further.

[Player701]

I don't normally use the melt effect (crossfade FTW), but I've tested g4.5pre-365 on my laptop (don't have access to my desktop PC right now), and screen melt appears to work just fine in both OpenGL and Vulkan. Graphics card is GTX 1050 Ti, driver version 456.71.

[sinisterseed]

Nay, it's still there in today's autobuild too, it didn't magically fix itself in the meantime.

[Rachael]

I hate to say it but I can't help but wonder if the divide between the "problem" and "just fine" is how modern the hardware is.

[Graf Zahl]

I had the same thought. I'm afraid but someone with affected hardware will have to go the painful route and narrow this down a bit closer.

[sinisterseed]

Good grief... well I guess I know what I'm doing today...

I'll check various commits from September 27th...

[sinisterseed]

Well actually no, it was much faster than expected since I had a pretty good feeling about when this could've broken after looking at the commit names - descriptive names and messages help a lot, that's guaranteed. Two branches is all it took me.

It's 96ceb11 - https://github.com/coelckers/gzdoom/com ... 52c3c0ab51 , the engine updates commit. The previous commit, https://github.com/coelckers/gzdoom/com ... 39c6d76a85 still works fine, but after moving to the next one the crawling screen melt surfaced.

It's not the texture manager update after all, but the engine one.

[Graf Zahl]

That commit only changes one thing that may be relevant - it changes the default of the gl_control_tear CVAR. Can you check if that may be the cause?

[sinisterseed]

I'll be damned, that's actually it. Fascinating.

So the tear control toggle helps us in Raze but in GZDoom it has side-effects in some edge cases.