How to deal with mismatch between fps and monitor refresh rate?

Question

Say I have a game running at some number of frames per second on a 60 Hz monitor. I would like to display my frames correctly in the sense that the in-game time difference between two consecutive displayed frames remains constant (e.g. 1/60 seconds). Now the allowed frame rates are 30, 60, 120 etc., and an obvious solution would be to enable vsync. However, with vsync enabled, the delta times are not exact multiples of 1/60 seconds, which means that I can't technically use them if I want the correct frame sequence. Instead, I would need to make the code explicitly dependent on the refresh rate. Is this even something to worry about, or should I just trust that the delta times are close enough? What if I use uncapped fps and the fps is high enough, should I then worry about fluctuations in elapsed in-game times between monitor refreshes?

Answer 1

However, with vsync enabled, the delta times are not exact multiples of 1/60 seconds, which means that I can't technically use them if I want the correct frame sequence.

It's not entirely clear what your concern is here. Generally, we don't care what the monitor refresh rate is - we care how many frames per second are actually getting rendered. This could be higher or lower than the monitor refresh rate depending on the game's graphics settings, the player's hardware, and the player's driver settings.

There are two ways to approach the speed/timing of motion and other gameplay mechanics:

• Frame updates: Using this approach, we update the game state once each time a frame is rendered. To ensure that the motion remains smooth even when the gamplay is changing, we scale the motion for each frame based on how much real time has elapsed since the previous frame. Motion will generally look smoother on a wider range of devices. CPU usage will be lower on low-end devices (because fewer frames are rendered per second, we perform fewer updates) and higher on high-end devices (the inverse). Things can sometimes break if the framerate gets extremely low and you are performing so few updates per second that motion is extremely imprecise.

• Fixed updates: With fixed updates, we update the game state at a constant interval (such as 60hz) regardless of how many frames per second are being rendered. Although we could used fixed hardcoded values for things like speed and timing, it's best to scale the motion based on the fixed update rate (number of updates per second) so that we can easily change the fixed update rate in the future without having to change all of the speed/timing values in our game. CPU usage will be more consistent/less dependent on framerate. Motion will likely be more precise on low-end hardware where the framerate is low. However, you might get complaints from users with high-end hardware - for example, a user with a 240hz monitor might complain if they notice the camera is rendering at 240hz but objects are only moving at 60 hz.

Update @bananab0y, in response to your comments on this answer: you are thinking about this the wrong way. It is not "incorrect" to render 90 fps while the user only sees 60fps. You are thinking about rendered frames as if they are units of time, but that is not the case. The timing of our important gameplay mechanics should be independent of framerate. In other words, we don't say that the cooldown for an attack should be 30 frames or that a character should move .1 unit per frame. We say that the cooldown of an attack is a half-second or that a character should move 6 units per second. Each rendered frame simply shows the game state at a particular moment in time, just like how each frame of a movie shows what was happening in front of the camera at a particular moment in time.

Let's look at this a different way. Imagine we record 10 seconds of gameplay to a video file with a framerate of 60 frames per second. When we watch the video file, we see exactly what happened. Now, we reduce the framerate of the video file to 30fps and skip every other frame. Is this new 30fps video "incorrect"? The new video is still 10 seconds long and shows the same events over the same time period. It doesn't change what actually happened, or the speed at which it happened - it just changes how smooth the motion looks.

Answer 2

There's only two important times for developers to stress about their frame rate vs monitor refresh rate. When the assets you have are meant to render at a certain rate (16fps sprites vs 60hz monitor, or 30fps sprite vs a 144hz monitor). And when your game runs slower and non integer ratio to the refresh rate of the monitor.

Your question and further responses are confused, hinting this is an X Y problem, it doesn't appear you have the first two problems. While update rate problems are adresssed by the gaffer on games article, display rate is fixed via frame capping, vertical sync, and monitor hardware variable refresh rate. But if you expect players to not be able to run the game well within minimum requirements and settings, that's a performance bug in your game. Hitching, inconsistent frame rates, these are things for you to fix not just "work around".

If your concern are frame rates that exceed refresh rates, the typical solution is for the user to use frame rate limiting slightly below the monitors refresh rate (141 for 144hz) on combination with hardware variable refresh rate (gsync/freesync), and force vsync on top of that. The minute frame differences are eliminated, and high refresh rates appear smooth under this regime. Further latency can be mitigated with vendor specific technology (Nvidia reflex for example).

This process of figuring out the right settings is largely a process the user toys with, not you (and might be done via forced settings in their gpu vendors display settings). You just need to make sure the standard list of features are available to toggle both on and off in your game (frame cap, vsync, and possibly vendor specific latency tech). If you can't toggle these on and off, you have a bug in your game. If your game doesn't work with these features toggled on and off you have a bug in your game. If your game doesn't work with forced settings, it's a bug in your game.

Most popular engines do not have problems with these settings, and these ideas even appear inmlow level modern graphics APIs, so it's unlikely to be something the average developer needs to deal with specificically.