Screen tearing and slowdown
Moderator: Graf Zahl
Screen tearing and slowdown
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.
-
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
Re: Screen tearing and slowdown
What hardware are you using and when did this start?
Re: Screen tearing and slowdown
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.
The problem exists in gzdoom-g2.2pre-1867-g071485b and later. It was not present in gzdoom-g2.2pre-1875-gc9f93d9.
Re: Screen tearing and slowdown
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.
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.
You do not have the required permissions to view the files attached to this post.
-
- Developer
- Posts: 3651
- Joined: Sat May 13, 2006 10:30
Re: Screen tearing and slowdown
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).
Re: Screen tearing and slowdown
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.
Thank you very much.
-
- Posts: 152
- Joined: Tue Oct 25, 2011 13:05
Re: Screen tearing and slowdown
just wondering, does the game Works if you set to use the intel gpu to run gzdoom?
Re: Screen tearing and slowdown
No, the problems still exist when using the Intel HD4600 GPU.
-
- Developer
- Posts: 3651
- Joined: Sat May 13, 2006 10:30
Re: Screen tearing and slowdown
Or it may still be broken... I guess we'll see.
-
- Developer
- Posts: 798
- Joined: Sat Jul 23, 2016 7:53
Re: Screen tearing and slowdown
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.
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.

Re: Screen tearing and slowdown
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.
Re: Screen tearing and slowdown
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...
-
- Developer
- Posts: 798
- Joined: Sat Jul 23, 2016 7:53
Re: Screen tearing and slowdown
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?
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?
Re: Screen tearing and slowdown
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.
-
- Developer
- Posts: 798
- Joined: Sat Jul 23, 2016 7:53
Re: Screen tearing and slowdown
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?
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?