UPS and FPS - What should I limit and why?

Question

I'm currently writing a game using C++ and SDL2 and there's one thing that I'm wondering about - does it make sense to limit my frames per second (FPS) and/or my updates per second (UPS)?

I get the idea that if you limit the UPS, you essentially control the speed of the game - if the player moves 1px per update and you always update it 30 times per second, he'll move at a speed of 30px/s and you'll probably also relieve the CPU since the amount of calculations per second decreases. If you limit the FPS, the amount of drawcalls per second decreases, therefore you relieve your GPU. I hope I understood all of that correctly, if not, feel free to correct me.

My question is - what am I supposed to limit in my game? FPS? UPS? Both? Neither? Is there another, better approach to this? How is this done in most games and why?

Answers are greatly appreciated!

Answer 1

Yes, it does make sense.

As you said it will make less load on the system, which is good for thermals, and other applications.

However.... Your games logic should NOT depend on the updates per second. Therefore I recommebd you to take a look at deltatime, which will make your game independent of the updates per second.

I recommend you to take a look at this question. It explains pretty well how to calculate and use it. How to get and use delta time

Hope it helped!

Answer 2

The best answer is: It depends.

You don't have to limit neither one

Updates: If your updates are not bound to an upper limit, then game logic should be dependent on a delta time amount, to avoid running the game faster or slower depending on the machine where it is run. This is a very common approach used by many games, but it is not the only one.

Rendering: If rendering is not bound to an upper limit, the framebuffer might be presented in an incomplete or erroneous state, causing tearing artifacts. This is why many games employ Vertical Synchronization (v-sync)

You might limit both

Updates: Some games make use of fixed timesteps for some or all of its gameplay systems. This approach works just as you've described. The number of Updates Per Second is limited to an upper bound to ensure things don't move too fast on a top notch machine. This removes the need for delta timing. Some applications are better with fixed timesteps, some with delta timing. Choosing which approach will depend entirely on what exactly you are trying to achieve. The online book GameProgrammingPatterns has a chapter dedicated to game loops that touches on both architectures.

Rendering: Frames Per Second should be set to an upper limit to avoid the afore mentioned tearing problem, however, your application should not attempt to do that manually with some CPU lock. Instead, enable v-sync and let the underlaying hardware synchronize with the refresh rate of the monitor. By doing that, your game will be forward compatible with future monitors which might operate on a much higher frequency then the currently commonplace 60Hz. It is also worth noting that many gamers, in particular those into benchmarking, still prefer to run without v-sync to allow the highest possible frame rate. So it is sensible to allow enabling or disabling the feature during runtime.

What you shouldn't limit

If your game uses a polling-based approach to user input, e.g.: calls a getInput() of sorts to update controller states during the update step, then this is better if not limited. Or if limited, then set to a very high upper bound. The more often you query user input and act on it, the more responsive and smooth the game will "feel". The so called 60Hz games that we hear about nowadays are not updating AI and all world states at that rate, some are not even rendering that fast, but they query controller input at least 60 times per second and update the player avatar accordingly. Granted that this is only really relevant to fast paced action games.

Answer 3

There are two posts you may want to take a look at:

Fix your Timestep

Interpolated physics rendering

I find the discussions on the posts really invaluable, but in my opinion it makes the most sense when there is an important amount of physics simulation in the game. In summary, the idea is that simulation should have a fixed time step (otherwise the physics could explode at some point where the delta is too big), whereas rendering should be given freedom to run at the maximum rate possible. In order to synchronize both (the simulation and the rendering), the render state is interpolated by a factor that depends on how far the simulation is from the following update (remember that simulation is fixed).

Hope it helps.