Game Loop frame independent

1
votes

Is it admissible to let the game loop run as fast as possible? Currently I can set my desired fps, thus having a constant fps on all devices my game will ship to. Yet on faster mobile devices it would be nicer to have smoother graphics. I had a look at frame independent updating. When using frame independent updating, there is no need to pause a while (to achieve a desired fps) and there is no need to just update and not render if the updating and rendering takes to long in the game thread? Please clear me up.

3
javaandroidmultithreadinggame-loop

3 Answers

2
votes

My experience (and I'm not alone in this) is that it's generally a bad idea:

  • Testing/identifying bugs is much harder:
    • You will forget to factor in the frame time on certain things, and if your game usually runs at a fairly even framerate which occasionally drops/spikes, it will take you a long time to spot these issues. However they will be really obvious to people with devices which are radically faster/slower than your test device(s).
    • You open yourself up to all sorts of hard-to-find bugs involving floating point errors/etc. Errors might still appear ina fixed-FPS loop, but they will happen every frame rather than only on frames which happen to take exactly 3124 nanoseconds.
  • Realtime physics simulation is very difficult for non-fixed update intervals. Trust me on this one! You can get around this by using fixed time steps for physics updates, but this comes with its own risks.
  • You have to calculate things which could otherwise be constants. Very small on a case-by-case basis, but can add up. (This will depend on the nature of the game you're making).
  • If you're always running the CPU at 100%, it's going to chew through the user's battery that much faster.

My advice is to run your logic at a decent fixed framerate and render as often as possible, though there's no point rendering more often than you update the logic. If there's 'spare' time, then just sleep. The user's battery will thank you, and the user won't be wondering why their phone gets so hot when they play your game!

The key to making it feel smooth is to make sure that your fixed framerate for the logic updates is high enough. The fact is, above a certain framerate users will not notice the difference. How high is high enough will depend on the exact nature of your game, but 30 fps is fairly common for action games. The faster things the user can see move/change, the faster the fixed framerate wants to be - e.g. first-person shooters always want a higher framerate than strategy games.

Another option you can take is to create logical 'snapshots' and interpolate between them when you render. This is a common technique used to smooth multiplayer games, as described here. It also makes it a valid option to render more often than you update the logic!

EDIT: Hopefully clarified some things.

1
votes

You should absolutely not impose any artificial restriction on your frame rate. Run as fast as possible. Keep track of the time each frame takes (using deltas) and then you can use that to accurately compute the state of the next frame relative to time.

0
votes

That is correct. When you render as fast as possible - you're essentially updating each object based on a value proportional to the current time.

So when you have a rotating cube - it rotates X degrees per second and not X degrees per frame. This will ensure that on poor machines, intermediate frames are skipped and the cube's rotation will appear choppy. But on good machines, you will see a smooth rotation.