Hi,

Maybe this question is off topic (or future topic) but I've been thinking about it the whole day and I still haven't found a good answer. So, how should I approach a fixed framerate gameloop that is vsynced if I got a monitor that its Hz is different from the fixed framerate?

For instance, if my gameloop runs at ~60Hz (16.6ms) and the monitor is at 75Hz (13.3 ms), the swap buffers (Flip) will occur on every 2 vsyncs, cause I missed the first one and then I have to wait for the second, so my game will end up running at 38Hz (26.6 ms).
Are my assumptions correct? if so, what should I do to avoid it? should I not Vsync if the monitor refresh rate is different than the fixed framerate and let the tearing show up? What other options do I have?

Thanks!

Honestly, this is probably not the answer you were looking for, but I would never run a game at something other than the monitor refresh rate unless I turned vsync off.

- Casey

If I understood correctly I should manage to keep up with the vsync, whatever it is, even though it's like 144Hz?

It's not really that bad, but now I need to take into account that the game could run on different Hz, so I have to prepare the game for a fixed and variable framerate. Does that make sense?

You can detect the refreshrate of the monitor and set the fixed fps to that, and then when you go to update state every frame, tell it how much time has passed, which would be 1/hz seconds each frame. This would mean that a higher refresh rate setting would tell the state to update more frequently in smaller steps. If you can't hit the target fps, time won't advance at the right speed in your game. If this happens, you could cut your fps in half. 144 -> 72, 120 -> 60, 60 ->30, and flip every other refresh to keep things smooth.

Alternatively there are ways to decouple state update frequency from rendering altogether with a variable framerate and fixed, but adjustable, state update frequency.

There are a few reasons why you'd want your update step to be fixed independent of the frame rate. They typically boil down to some need for a repeatable simulation. This can happen when you want to record replay files of the controller input or you want to synchronize clients over a network (small rounding errors with each frame time eventually accumulate into desynchronization).

But I agree with Casey in that you probably don't need/want to do this.

If you do need to do this then what you want is called "dead reckoning". Basically you update the game at a fixed step and have some extra data for predictions (either saving the previous update or a storing behavioral model), then based on the frame time you blend between two updates or project into the future. Warning, thats a huge oversimplification. There is no one right way to do this. Each game will require different techniques.