Gametime / FixedTimeStep / FPS / Vsync / etc

1

Hello,

I know this article: Understanding GameTime which is great.

The following questions remain a mystery for me though. Any input appreciated. Thanks!

  1. Is there any point in having a fixed time step and vsync off? My game has fixed time step and currently I offer VSYNC as an option in the settings. When I deactivate it on my machine, the result is horrible / stutterish. Should I not give this option at all or do you know of any scenario where fixed time step + vsync off might make sense? (my time step is at 60 FPS)
  2. I found this article through another forum post: Fix Your Timestep! | Gaffer On Games
    The last method seems interesting (scroll down to “THe final touch”). However I wonder: Doesn’t this approach mean that what I render will always be 1 frame behind of what the current physics-state is? Is the implication input/output lag?
  3. This one might be connected to question 2: I read here and there that you should process input as soon as its there independent of the physics frame rate. Now this doesn’t really make sense to me. Player movement etc, is part of the physics isn’t it? (or do I get the model wrong?) Now what should the input do, if there is no physics to process it? Thanks for enlightening me :slight_smile:

Cheers

2

  1. If your game is slow paced turning VSync off will result in a smoother image (less choppy) - a good example is city skylines, It still feels fluid even with 15 FPS when vsync is turned off, as vsync would otherwise introduce additional waiting times, which makes a difference when FPS is already subpar

  2. Every Multiplayer Game basically has a input/output lag of several ms - it’s just covered by smart inter/extrapolation but it’s there - even a regular game with vsync has a input/output lag until the screen is rendered - anyway, a frame is 16 ms (60FPS) so noone will notice.

  3. not sure what the actual question is … input will dictate the next steps in the update loop, whatever that is - and you dont even get the exact point of when it’s happening. In your update loop you check if key is currently pressed or not - you dont get the exact tick when it was actually pressed. You are just quering the current input state, whenever you run update - so its always tied to whatever your update loop is (not necessarily render loop, where update can run multiple times between each frame)

3

Thanks for your response @reiti.net, much appreciated!