[all games] Uncapping framerate while running a listen server changes game speed

[xenonnsmb]

Description

On recent versions of Source (HL2 beta branch and latest release build of TF2), running the game at an uncapped framerate in singleplayer (running a listen server) makes the game physics faster than normal. To reproduce, set fps_max 0 and mat_vsync 0, then start a listen server--it's easy to notice by jumping, you'll land faster than normal. For whatever reason enabling sv_cheats fixes this; binding a key to toggle sv_cheats and pressing it while jumping will make the issue especially obvious.

System information

https://gist.github.com/xenonnsmb/4d6f72413ac99e8b518b170feb380c30

[Pinsplash]

My original test of this was just recording jumping with fps_max 0 and with fps_max 300, then observing the number of airborne frames in a video editor. I couldn't find any difference. It was the exact same number of frames.

In the spirit of being thorough, I considered if this was due to an FPS cap being set by my video recorder. I did notice it kind of felt like the timing was different, but it could've been my imagination, so to be sure I made a map to time jumps. If there's really an easily noticeable difference in game speed, it should catch it in spite of the accuracy problems detailed below. The idea is you sit in a trigger, then when you leave the trigger by jumping, a logic_timer runs rapidly, and when you land back inside the trigger, the timer stops.

https://drive.google.com/drive/folders/1I-syO0IZs3WFepnKxZF1NuKpPkUE_7xN?usp=sharing

There are problems with this approach: A. The trigger's ceiling has to be 1 unit (or any other small small amount) above the ground so that you're actually considered to be touching it, so the time it begins recording at is slightly after you jump and the time it stops is slightly before you land. B. The logic_timer can't fire every centisecond, as the default tick rate is 0.015, and if this game speed thing is true, I think it's reasonable to presume that tickrate is a variable that needs controlling. C. The logic_timer appears to not fire perfectly periodically, even if the interval is 0.015. I chose the interval 0.02 because it seemed to work just as good as anything else.

With all those flaws, a soldier is airborne for 44-45 "cycles" (~0.717 real time) after jumping. Sometimes in the first few moments after a round reset, 46 is also possible, but after a number of seconds, it is not. Terrifying! but not what we're after. The behavior is the exact same regardless of fps_max. (On my system, barring the possibility that uncapped FPS + sv_cheats 0 makes a tick itself pass by faster, which would possibly not be detected by this method.) I also tried eyeballing (earballing?) the difference in time between a rocket firing and exploding and it didn't sound different to me.

@xenonnsmb Try jumping on this map and see if the numbers are consistent on your system.

My system information https://gist.github.com/Pinsplash/604c266611680caa5e1d7e02e5924f30

[xenonnsmb]

@Pinsplash Using your map, I got consistent on-screen numbers regardless of fps_max and sv_cheats, but I was still able to tell the difference in jump speed; the attached video demonstrates this side-by-side in HL2 using Source Pause Tool to automatically re-jump. The two videos become desynced due to the difference in jump speed when theoretically they should stay in sync forever as the jumping is tick-perfect. Because of this, I can only assume that uncapping the framerate while sv_cheats is disabled actually causes ticks to pass faster.

https://user-images.githubusercontent.com/11357889/147840068-daf53e85-0f95-4428-aaf5-2c9ee4238061.mp4

In my testing I was able to reproduce this issue on versions of the engine as old as SDK Base 2007, it isn't actually new as I thought. Perhaps there's some kind of weird Nvidia driver stuff at play here; when I get the time I'll test this on a fresh installation and on different hardware to see if I can reproduce it.

[TheJman494]

Hello, I though I would add to this as I have encountered the same issue recently in the HL2 Beta Branch.

For Valve, my support ticket: HT-3KK2-7678-KTPF Related Github Issue from 2013: #1130

I've experienced this issue in the past with both of my PC's, an older build (rarely) and a very new build (very frequently), in various single player Source 1 games.

Older build

• i7 3930k
• GTX 980
• Win 8-10

New build

• Ryzen 7 5800X
• RX 6900 XT
• Win 10

With the recent Vulkan beta Launch Options: -gamepadui -vulkan this speed problem has been made much worse as Vulkan is running much better at significantly higher FPS, a blessing and a curse, I've seen as high as 3400 FPS in some small areas.

I've captured 2 examples I would like to share, from the current Half-Life 2 Beta Branch as of 1-26-2022.

You can hear how fast Gordon swings the crowbar, and watch how fast the Zombies can walk. You can see when I change fps_max in the console.

D3d9 Test: Launch Options: -gamepadui https://www.youtube.com/watch?v=tvXG0r4KRxM

Vulkan Test: Launch Options: -gamepadui -vulkan https://www.youtube.com/watch?v=eNh22YPlQao

[tmob03]

This isn't exclusive to newer source branches, and it occurs over 999 fps, the game doesn't process ticks right or something, i'm not sure the exact reason but it's due to the tickrate going wonky