[BUG] Rendering Performance Regression from 4.12.2 to 4.13

[soliddew]

GZDoom version

GZDoom 4.14

Which game are you running with GZDoom?

Doom 2

What Operating System are you using?

Windows 11

Please describe your specific OS version

Windows 11 Pro

Relevant hardware info

9800 x3d, RTX 4090

Have you checked that no other similar issue already exists?

• I have searched and not found similar issues.

A clear and concise description of what the bug is.

On large maps pre 4.13, looking in a direction that wasn't expansive would restore the lost FPS. After 4.13.0, there is a breakpoint in widescreen resolution (viewport) that causes this to not happen anymore, meaning the FPS stays lost.

Test location: Sunder Map 15 pos: -3183, 8943, 9017 (jammed into the northwest corner of the map facing the corner). I've tested Supplice maps that also have this issue which are even more pronounced than this one.
GZDoom 4.12.2:
Default Resolution: 3440 x1440 550 fps
Cranked Resolution: 6880 x 2880 500 fps

GZDoom 4.14:
Default resolution : 3440 x 1440 220fps
Good resolution : 2924 x 1440 660 fps
Bad Resolution : 2925 x 1440 230 fps

I ran GZdoom in debug mode but it was hard to find a direct culprit other than a drastic increase to HWWall::Process and Clipper::PointToPseudoAngle, but that could just be normal rendering stuff instigated by another issue. I do see a change that includes widescreen ratio (Clipper:PointToPseudoOrthoAngle) in 4.13.0 but this is out of the realm of my expertise (crashing my game with infinite 0 state loops).

I don't think this is an ultrawide thing, I had two other tests ran on different hardware where I was able to replicate similar effects. Tested in Vulkan and OpenGL. Sometimes the breakpoint is different as well, in my Supplice test map it's 2524 x 1440 and in Sunder it's 2925 (same ini and executable). I swear it was 2524 in Sunder at some point but my brain may be melting from staring at lava.

Steps to reproduce the behaviour.

Explain how to reproduce

1. Use GZDoom 4.13.0+ in Sunder Map 15 at -3183, 8943, 9017 facing the wall
2. FPS should be the roughly same as looking at the expanse behind you.
3. Use vid_setscale and binary search until your FPS is restored, then find the breakpoint.

Your configuration

Default GZDoom.ini
https://gist.github.com/soliddew/6bb934c6b55e7fad17826572d245c2ef

Provide a Log

No error logs

[madame-rachelle]

Between those versions there was this issue: #2726 - it was fixed with an external PR with what I recall a warning that FPS might go up in certain rare cases.

There's never a one-size-fits-all with these things and it was determined that it was better to bite the bullet and fix the rendering issues, and accept the potential loss of FPS, than to let that problem stand. No matter who you ask chances are their opinion would have been different with how to handle that - so there's really no pleasing everybody.

I'm leaving this open on the off chance someone might be able to figure out a way to fix this without having the rendering issues mentioned in that post - but - you might want to be on the lookout for VkDoom, since it seeks to render the entire level as a one-time mesh which may help address these FPS issues.

[soliddew]

I checked out the latest VKDoom dev build and it exhibits the same behavior, but it may have always been like that.

Is there a chance it could be a settings toggle? We all know that gamers don't look up 99% of the time anyway :)

I appreciate you taking a look at this. Thanks

[RicardoLuis0]

I checked out the latest VKDoom dev build and it exhibits the same behavior, but it may have always been like that.

yeah, levelmesh in vkdoom is still experimental, you can try it with gl_levelmesh true in the console, but it will have some visual discrepancies especially in maps that use vanilla hacks and the like