11
\$\begingroup\$

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!

\$\endgroup\$
10
\$\begingroup\$

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!

\$\endgroup\$
  • \$\begingroup\$ So should I limit both or just one of them? \$\endgroup\$ – DocCoock Jun 6 '15 at 20:03
  • \$\begingroup\$ Both, but add an option in the settings to adjust. \$\endgroup\$ – KaareZ Jun 6 '15 at 20:06
  • 5
    \$\begingroup\$ A word of caution: if you use a physics engine, do not rely on delta time/variable update frame as these are rarely supported; they require the fixed frame approach. And if your frame fluctuates a lot, this might mean you have issues with your software and should wonder why this happens. Given these, you might re-consider using the DT approach. \$\endgroup\$ – Alexandre Vaillancourt Jun 6 '15 at 23:48
  • 1
    \$\begingroup\$ Note that using updates based on delta time can lead to physics instability and bugs that are very difficult to reproduce. In some games, there are tricks that are only possible at certain frame rates. This is why physics often runs at a fixed frame rate. You can always interpolate at lower update rates, but if your simulation is unstable, nothing can help you. \$\endgroup\$ – Dietrich Epp Jun 7 '15 at 12:45
  • 1
    \$\begingroup\$ Honestly, I think deltatime is not a good idea. I have used it for years, and it comes with two major issues. Lots of different multiplayer articles recommend using fixed time steps for, and if the deltatime goes too high, then you can teleport through walls or similar bugs unless you take that into account. \$\endgroup\$ – Programmdude Jun 7 '15 at 14:07
6
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ My updates are automatically limited too when VSync is enabled, though. Therefore, I apparently have to decide between the tearing-problem and the update-polling-problem, correct? \$\endgroup\$ – DocCoock Jun 13 '15 at 21:54
  • \$\begingroup\$ @DocCoock, if your renderer and game logic run on the same thread, yes, enabling v-sync also fixes the update frequency. That's one reason some games segregate rendering and game-logic to different threads. \$\endgroup\$ – glampert Jun 14 '15 at 2:33
1
\$\begingroup\$

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.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.