Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Read <a href="http://dewitters.koonsolo.com/gameloop.html" rel="nofollow noreferrer">this page</a> about game loops.</p> <p>In short, set a timer:</p> <ul> <li><p>Update the state of the game at a <strong>fixed</strong> frequency (something like every 25 ms = 1s/40fps). That includes the properties of the game objects, the input, the physics, the AI, etc. I call that the <strong>Model</strong> and the <strong>Controller</strong>. The need for a fixed update rate comes from the problems that may appear on too slow or too fast hardware (read the article). Some physics engine also prefer to update at a fixed frequency.</p></li> <li><p>Update the frame (the graphics) of the game <strong>as fast as possible</strong>. That would be the <strong>View</strong>. That way you'll provide a smooth game. You can also enable vsync so the display will wait for the graphic card (usually it's 60 fps).</p></li> </ul> <p>So each iteration of the loop, you check if you should update the model/controller. If it's late, update until they are up to date. Then, update the frame once and continue your loop.</p> <p>The tricky part is that because of the different update rates, in fast hardware, the view will update several times before the model and controller. Therefore you should interpolate the position of your game objects depending on "where they would be if the game state would have been updated". It's really not that difficult.</p> <p>You may have to maintain 2 different data structures : one for the model and one for the view. For instance you could have a scene graph for your model and a BSP tree for your view.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload