5
\$\begingroup\$

I know this question has been asked a lot, but I never found an answer suitable for me. I have a game with a fairly big logic system and the movement system I am currently using is calling SDL_GetTicks() and measuring the delta time between the frames. I multiply the delta with the speed and I get the pixel movement. The problem with this is that the CPU usage is quite high. I didn't really mind it until my friend started going on about how it was "the end of the world".

The question I really want an answer to is if I should cap the framerate, and if a high CPU usage is unwanted (or even dangerous!).

\$\endgroup\$
5
\$\begingroup\$

Should you cap the framerate: Yes

Is a high CPU usage unwanted: Yes

Or even dangerous!: Could be but if so not your problem


You want to cap the framerate because you are extremely unlikely to achieve any benefit (to your game) by calculating at a frequency higher than your ability to display the results. ie, if your monitor can only display at 60Hz then displaying at 200Hz achieves nothing because the display will a) ignore frames and only display at 60Hz anyway or b) display ugly tearing.

The high CPU usage is unwanted because you are drawing unnecessary current from the CPU and from the GPU, raising the temperature, fan speeds and your unsuspecting customers power bill :-)

Running at 100% CPU usage across all CPU's and flatlining the GPU simultaneously may possibly cause some system to overheat and even fail, but that would only be because that system is misconfigured (or improperly overclocked). So such a system failure would primarily be caused by the configuration error, you just triggered it. If you follow the above two guidelines this becomes a moot point.


Related to this is the internal logic & movement system which while not strictly tied to the framerate in theory, in practice it often is. The human eye very sensitive to tiny fractions of a second difference, particularly where it relates to input and game response to the input. So it's a really good idea to check player input only immediately before updating game characters, and also to put that part of the code as late in the game loop as is feasible.

The trick is doing all this as close as possible to your frame time slot without going over and missing your refresh.

For example at 60Hz you have 16ms per frame, and if your main loop takes 6ms, it's better to execute it at the 9ms mark rather than at the 0ms mark and lagging by 10ms.

Executing it as late as possible with a tiny leeway will make it feel just that touch more responsive, and gamers will notice.

Keep your loop timing tied to the vsync signal rather than some arbitrary random game start time. Also keep in mind that high res timers will derive over time so you'll need to watch it to keep it in sync. This way your 6ms main loop won't accidentally finish a millisecond after the screen refreshes so that you have a whole 15ms lag.

If you think it's ridiculous to say that a player would notice such a small interval, then go read this 2006 study to see just how quick the human eye is (this article includes a cognitive response to a massive amount of visual data in it's timing).

Also note player comments where they are adamant about noticing game responsiveness when the refresh rate is in fact beyond the ability of their monitors to display it.

It is because the very freshest data was used when drawing the frame they do see.

Also be careful as vsync synchronisation can make your program 'freeze' for a few ms while waiting for vblank. There is an excellent discussion of the vsync issues over at virtualdub.org as well as one at opengl.org on swap interval (read the talk page on opengl.org as well)

\$\endgroup\$
  • \$\begingroup\$ Even display would cap at 60Hz, it does not mean you can't see the difference between 60 and 100FPS. There is difference, anyone who plays all days knows this. Overall your answer is still good. Game that uses 100% CPU is doing something funny, but it certainly wont do any harm for you ( unless you play that game 24/7 (don't think it would do anything still)). Natural selection 2 and BF3 are notorious for using 100%CPU, still played all around the world. \$\endgroup\$ – Katu Jun 30 '14 at 14:53
  • \$\begingroup\$ I must beg to differ :-) You can't see what the display doesn't show, and a 60Hz display only shows at 60Hz, not a fraction more. What may happen is that it will look slightly worse because 100 isn't evenly divisible by 60 so it would display at a even lower actual rate, or as mentioned, tear - which actually happens would vary depending on the monitors design. However, some physics designs might benefit from a smaller delta time but they are much more likely to actually deteriorate as @Eejin describes. Requiring small delta times is a sub-optimal design, best avoided if possible. \$\endgroup\$ – Ian Macintosh Jun 30 '14 at 17:30
  • \$\begingroup\$ Game update speed != screen refresh rate. If i play Counter-strike 1.6 with FPS cap at 60-80, i see tearing, if i use v-sync i feel input lag. I set cap to 100 and it's all gone. However, lets not go deep siderail. My point was, cap FPS, but allow user to change it. My Plasma has 600Hz ( yeh, not same as LED/LCD rate) and it's nice to push FPS little bit up when playing. \$\endgroup\$ – Katu Jun 30 '14 at 19:33
  • 1
    \$\begingroup\$ Agreed @Katu. You are right that FPS != game update speed. FPS is the ability of the game constrained by monitor refresh rate to display a frame on-screen. I was answering the question rather directly. However what you are mentioning is often tightly tied to FPS. I will try expand the answer above to add some more detail about that because you do bring up a valid point and it is worth considering the relationship between the game update speed and the frame rate. \$\endgroup\$ – Ian Macintosh Jul 4 '14 at 13:58
  • \$\begingroup\$ Do that and i vote you up! \$\endgroup\$ – Katu Jul 4 '14 at 14:16
0
\$\begingroup\$

There are a couple of dangers with an unlimited framerate which I will try to explain

You already use delta time which means that a computer which would not reach 60 FPS should still be functional. But what if I have a monstrosity of a computer that is able to run the game at 600 FPS. Deltatime will become really small and in combination with floating point errors may cause unexpected behavior as there may be rounding errors.

So you would say that capping the game at 60 FPS might be a good idea. Only downside is that the person with the 120 Hertz monitor won't be able to play at 120 Hertz.

So you might want to cap the framerate at 60 or so and provide an option to run at 120 or 240 Hertz.

\$\endgroup\$
  • 1
    \$\begingroup\$ Also, capping at 60FPS (or 120 with a option), uses much less CPU. Some simple games often don't do capping, and people with high-end computers find themselves overheating with no added benefit (and even more, with possible screen tearing!) \$\endgroup\$ – Kroltan Jun 30 '14 at 9:39
-1
\$\begingroup\$

No, you should not cap the framerate. This is using unnecessary processing power to check and handle the framerate. It is not necessary to base timings on the framerate, eventually computer screens will be able to handle 120Hz, so allowing the computer to zip as fast as it can is better. It will not hurt your processor to run fast, because it only uses one core to the max, unless you have a multithreaded application. Everywhere I go I see people capping the frame rate, but I believe it is useless.

\$\endgroup\$
  • \$\begingroup\$ Please no. It's my computer, not yours, and I don't want your game to kill my battery. Also, how does it make sense to say capping the frame rate uses unnecessary processing power when doing so reduces CPU usage? \$\endgroup\$ – Radon Rosborough Sep 10 '17 at 22:06

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.