Stuttering when running at reduced gamespeed

[jengelh]

Regression introduced by

d6f2545bced66cb321e166f27dc62e3121dedb62 is the first bad commit
commit d6f2545bced66cb321e166f27dc62e3121dedb62
Author: Fabian Greffrath <fabian@greffrath.com>
Date:   Mon Nov 15 13:21:37 2021 +0100

    attempt to fix stuttering with uncapped framerate (#421)
    
    * attempt to fix stuttering with uncapped framerate
    
    Based on the code from DSDA-Doom and instructions by @kraflab.
    Hopefully fixes #400.
    
    * apply the Crispy Doom fractionaltic calculation formula

 prboom2/src/SDL/i_system.c | 45 ++++++++++++---------------------------------
 prboom2/src/d_client.c     |  1 -
 prboom2/src/i_system.h     |  2 --
 prboom2/src/m_misc.c       |  2 --
 4 files changed, 12 insertions(+), 38 deletions(-)

when running at 60% gamespeed and other some other rates, I get stuttering on Linux-X11-SDL.
System is openSUSE Tumbleweed x86_64 with libSDL2-2_0-0-2.0.20-1.1.x86_64, Mesa-21.3.5-300.2.x86_64, libdrm_intel1-2.4.109-1.2.x86_64, and uncapped in-game framerate.
(Commit prior to d6f2545 runs just fine at all gamespeeds with the same config.)

[fabiangreffrath]

This has already been reverted by this commit:
863702b

Could you please check again from a recent snapshot? I don't experience any stuttering at any game speed.

[jengelh]

I did try this with 2.6.2, then bisected to that commit. The changelog had me already raise an eyebrow. The #421 kind of stuttering is eversoslightly different. Here [220MB] is a screencapture of my experience, on 2.6.2, with some cyberdemon being displayed erratic. Perhaps as a result of repeated speedshifting, there's a loss of accuracy somewhere?

[fabiangreffrath]

Do you have uncapped framerate and/or vsync enabled?

[jengelh]

uncapped_framerate                1
render_vsync                      1

[fabiangreffrath]

Hm, I can only say that the game runs butter smooth with these settings for me, even at reduced game speed.

[fabiangreffrath]

Do you reduce the game speed in the menu and restart the engine or do you change it in-game with the "change game speed keys"?

[jengelh]

In-game with mousewheel and/or with a set of keys, yes.

[fabiangreffrath]

Could you try to set it in the menu (General, second page), restart the engine and try again?

[jengelh]

The issue resets between program restarts. When the game has reached a state where jaggy motion is noticable, loading a savestate though retains the problem. A hypothesis out of the blue is that there's some time/tick counter…

and indeed it is. I created a testcase at https://github.com/jengelh/prboom-plus/tree/testcase . Start prboom with a gamespeed of 50 (no need to ever change it in game) and play.

This overflows:

  int i = t * TICRATE * realtic_clock_rate / 100000;

t being 1560000 ms * 35 * 50 -> 2.73*10^9, which is no longer representable with int, and in practice wraps around to become -1564967296.