Killer Game Programming in Java

FPS and UPS

Apart from FPS, there is another useful measure of animation speed: UPS. The current animation loop carries out one update and one render in each iteration, but this correspondence isn't necessary. The loop could carry out two updates per each rendering, as illustrated by the following code fragment:

    public void run()
    // Repeatedly update, render, sleep
    { ...
      running = true;
      while(running) {
        gameUpdate();   // game state is updated
        gameUpdate();   // game state is updated again

        gameRender();   // render to a buffer
        paintScreen();  // paint with the buffer

        // sleep a bit
      }
      System.exit(0);
    } // end of run()

If the game offers 50 FPS (i.e., 50 iterations of the animation loop per second), then it is doing 100 updates per second.

This coding style causes the game to advance more quickly since the game state is changing twice as fast but at the cost of skipping the rendering of those extra states. However, this may not be noticeable, especially if the FPS value is 20 or higher.

Separating Updates from Rendering

One limitation on high FPS rates is the amount of time that the update and render steps require. Satisfying a period of 5 ms (1000/5 == 200 FPS) is impossible if these steps take more than 5 ms to accomplish. Most of this execution time is usually consumed by the rendering stage.

In this situation, the way to increase game speed is to increase the number of UPS. In programming terms, this translates into calling gameUpdate() more than once during each iteration. However, too many ...