PrBoom Plus 2.5.1.4 uncapped frame rate issues

When I enable uncapped frame rate in version 2.5.1.4 of PrBoom Plus, the game's frame rate seems to be a lot less smooth compared to other ports with uncapped frame rate. I don't know if this is intended or a bug. And, is there any way to fix it?

1 hour ago, Sector 147 said:

When I enable uncapped frame rate in version 2.5.1.4 of PrBoom Plus, the game's frame rate seems to be a lot less smooth compared to other ports with uncapped frame rate. I don't know if this is intended or a bug. And, is there any way to fix it?

I experience the same thing. However when I turn off vsync, things become smooth (albeit with some tearing here and there).

Same here. The feature looks broken. But this should work properly with VSync on. It's actually one thing I immediately noticed when testing my own fork.

13 minutes ago, Graf Zahl said:

Same here. The feature looks broken. But this should work properly with VSync on. It's actually one thing I immediately noticed when testing my own fork.

It should work with both options turned on but sadly it does not. VSync gives me a choppy game in most SDL-based ports on my end (Doom Retro, Eternity, and PrBoom+), apart from Chocolate Doom devbuilds, and Crispy (both stable and devbuilds now). GZDoom is great with vsync on. I also don't seem to be anywhere near the only one experiencing this.

I hope you'll eventually figure out what causes this problem and fix it in your fork, so that vsync becomes a viable options for some of us.

It it's an SDL bug it may be necessary to swap out the entire backend. Let's hope not, because right now far too much depends on it. For me this is the biggest issue keeping PrBoom from being usable.

1 minute ago, Graf Zahl said:

It it's an SDL bug it may be necessary to swap out the entire backend. Let's hope not, because right now far too much depends on it. For me this is the biggest issue keeping PrBoom from being usable.

Let's hope not indeed since that's likely a major undertaking.

But... it could be an issue with SDL honestly, otherwise I don't see how it can happen in multiple ports that rely on it.

Or maybe ask Fabian for some help as Crispy Doom is also SDL based but it runs really smooth with Vsync ON.

Does Crispy have uncapped frame rate?

Yes it has uncapped framerate.

This is just a wild guess, but last year it made a huge impact to change to place in the code where the fractional tic to use for interpolation was calculated. It seemed we could achieve the best results if the fractional tic was calculated exactly after the previous frame has been rendered:

https://github.com/fabiangreffrath/crispy-doom/commit/e2f5a2d3775e29794a666aa36489fff5dc57ce5b#diff-7e61dc47251785545445d15441b9a87f

Indeed. The same thing also helped a lot in GZDoom, when setting up the fractional time in R_SetupFrame it doesn't properly deal with the playsim's thinking time.

Only, on GZDoom it required rather large maps to become noticable, as long as the think time was low it was barely noticable.

Also when I turn off uncapped frame rate, the game runs at like 20 fps rather than 35 fps

Could also be related to frame timing issues, which I know Vulkan at least provides ways of dealing with. I can't notice any stutter in EE so it's hard for me to test, and every time I try adopt Crispy's fix it seemingly works for one build, then magically breaks. It's like the program is gaslighting me. @Graf Zahl do you use VK_GOOGLE_display_timing in the Vulkan renderer for GZDoom to schedule presents so that they don't happen too early, in order to minimise stuttering?

29 minutes ago, Altazimuth said:

I can't notice any stutter in EE

It's not stuttering though.

The problem is that with VSync stuff just isn't very smooth like it is without it, and that can be easily felt in the mouse when moving it across the screen at various speeds. Crispy, Choco devbuilds, and GZDoom don't have this problem so there must be something, somewhere that they did to remedy this.