0
\$\begingroup\$

Lets say I have a simple game loop (variable timestep - but it applies also for other timesteps):

double lastTime = SDL_GetTicks();

while(isRunning){

    double currentTime = SDL_GetTicks();
    double elapsed = currentTime - lastTime;

    processInput();
    updateGameWorld(elapsed);
    render();

    lastTime = currentTime;
}

My FPS increases drastically to 4k+ and CPU to 80%+ (actually it was very simple app) and I had to limit the FPS anyway (which I think is destroying the timestep). My question is: is locking FPS necessary or I'm doing it wrong?

\$\endgroup\$
0
\$\begingroup\$

Is locking FPS necessary or am I doing it wrong?

No, locking the framerate is not necessary.

However, you may consider the following reasons to use a fixed timestep:

  • Better consistent behaviour across all the devices. If you cap your framerate at 60 hz, and you can guarantee that your minimum specs machine can run the game at that framerate, every users will experience the same simulation.
  • Most monitors are capped at 59-60hz (this is less and less true, I think). There is no point in trying to go faster.
  • On devices that run on battery, more frames per second == more computation and rendering, this results in battery getting drained faster.
  • I find it easier to think in fixed timestep.
\$\endgroup\$
  • \$\begingroup\$ I´ve tried the fixed timestep before. It worked good , but when I tried to slow the objects down(i mean, low speed like 0.05f) the movement was choppy and I started investigating the problem to find out whats the main problem. But without fps cap, how can I avoid 90% CPU usage? \$\endgroup\$ – Pins Feb 20 '17 at 13:53
  • \$\begingroup\$ @Pins " low speed like 0.05f" I'm not sure 0.05f qualifies as a speed. It's just a number; a speed is a number representing a distance (or a measurable unit) over a span of time. What do you mean? \$\endgroup\$ – Vaillancourt Feb 20 '17 at 13:57
  • \$\begingroup\$ I mean i have a speed vector, and in update method I perform the movement like this: _position.x += _speed.x * deltaTime \$\endgroup\$ – Pins Feb 20 '17 at 14:02
  • \$\begingroup\$ @Pins This example shows that the speed is 0.5 per second. It does not show whether you're using fixed or variable timestep, and it doesn't show how/why the movement was choppy. Maybe you should ask a new question with this issue. \$\endgroup\$ – Vaillancourt Feb 20 '17 at 14:11
  • \$\begingroup\$ "But without fps cap, how can I avoid 90% CPU usage?" Aside from using an engine that does it for you, or having the graphics driver limiting it (on windows/NVidia, for instance), you can't. \$\endgroup\$ – Vaillancourt Feb 20 '17 at 14:12
0
\$\begingroup\$

Yes, you should still limit the FPS.

  1. Even if you have a variable timestep, extremely short timesteps can cause weird behavior in some situations due to floating point inaccuracies.
  2. Extremely high framerates can cause the GPU to overheat.
  3. Rendering more frames than the human eye can perceive is simply unnecessary waste of system resources. It slows down other processes on the user's device and it will unnecessarily drain the user's battery or ramp up their electricity bill.
\$\endgroup\$
  • \$\begingroup\$ In addition to point 2, users may experience coil whine on some GPUs, which might make them think the game is harmful to their computer. \$\endgroup\$ – wondra Feb 21 '17 at 0:22

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.