Screen tearing and slowdown

[Guest]

As of recent versions, still present in gzdoom-g2.2pre-1905-gc0b8627, the screen tears a lot and the game runs much less smoothly. Turning Vsync on, then off again, fixes the issue, but this needs to be done every time GZDoom is launched. This issue only seems to affect the hardware renderer, and as such is not present in ZDoom.

[Graf Zahl]

What hardware are you using and when did this start?

[Guest]

I have an Nvidia GTX950M GPU, Intel Core i7-4720HQ 2.6GHz CPU.

The problem exists in gzdoom-g2.2pre-1867-g071485b and later. It was not present in gzdoom-g2.2pre-1875-gc9f93d9.

[Guest]

Forgive the double-post, but I just noticed another issue I was about to report seems to have started in the same version, so I wonder if perhaps they're related.
When running hardware renderer, the player's camera seems to be angled too high. As such, shots are landing much lower than they look like they should. The software renderer (vid_renderer 0) does not have this problem, and as such, neither would ZDoom.

These screens were shot in the exact same position, having not moved the player or the viewing angle. Bullet holes on the mirror in the first shot demonstrate where level shots are landing. The mirror doesn't work in software renderer, so the wall turns into a void in the second shot, but the difference in viewing angle should still be easy to notice.

Screenshot_Doom_20160801_154339.png

Screenshot_Doom_20160801_154249.png

[Rachael]

That's a problem with the screen being shrunk, and it's due to the new bloom and tonemaps code. AFAIR the bug has already been fixed but apparently either you didn't pick up that build or it hasn't been uploaded yet (haven't had a chance to check which that is).

[Guest]

As mentioned, these are both present in gzdoom-g2.2pre-1905-gc0b8627, which is currently the newest one uploaded. So if these are already addressed, I will simply wait for tomorrow's build.

Thank you very much.

[ibm5155]

just wondering, does the game Works if you set to use the intel gpu to run gzdoom?

[Guest]

No, the problems still exist when using the Intel HD4600 GPU.

[Rachael]

Or it may still be broken... I guess we'll see.

[dpJudas]

Think my fixes should be in the nightly builds by now. Are you still experiencing those issues?

Edit: actually never mind. Seems gzdoom-g2.2pre-1905-gc0b8627 is still the latest automated build. Anyhow, when the next comes up please let me know if its still broken. Otherwise I'll assume it isn't.

[Guest]

A new dev build was finally posted this morning, and I am reporting to confirm that the issues seem to be fixed now. Thank you all very much for your efforts and input.

[Guest]

It seems I spoke too soon, actually... The issue with the camera aiming too high is indeed fixed, and while my first session with the new build proved smooth, it seems that the screen tearing and slowdown are back. I can still fix this by turning vertical sync on, then off again, but this is quite a nuisance...

[dpJudas]

How does the screen tearing look like? When vsync is off there's always going to be some screen tearing, that's what vsync is supposed to prevent.

About the slowdowns, is this an occasional drop in frame rate? Or is it constant? What are roughly the min/max/avg frame rates that you are getting and on which map?

[Guest]

The tearing makes it look as if there's a diagonal line through the screen, from top-left corner to bottom-right. It's incredibly visible when the player is moving. The slowdown is most severe when first entering a map, but then begins to relieve a little bit after a few seconds (though it never becomes as clean as it does after I set vid_vsync to 0, even if it was already 0). Rather, it's more like 'dropped frames' than slowdown, since the game world is still running at normal speed, it just all looks incredibly jerky. vid_fps is reporting anywhere between 20 and 40 when the problem is at its worst, topping out at 60.

[dpJudas]

Based on your description it sounds like a screen quad rendering where one of the two triangles are missing. How this can happen I have no idea. I've been reading up on persistent mapping in OpenGL to see if I could find any error in how gzdoom is doing it, but so far everything seems to be done by the book.

I'll try create a special build tomorrow where that part of the code always uses a static vertex buffer. It will help rule out that it has anything to do with the vertices. Are you able to build from source or do I need to build an executable for you to test?