Controlling Game Updates

It's important to understand that, by default, Slick calls the render() and update() method of your game on every frame. This obviously is necessary for the render() method, but may not be what you want for the update() method. Since framerates vary from one computer to another, or even from one scene to another, calling update() on every frame can make your game logic a little unpredictable.

The GameContainer class has a built-in solution for this. It has two properties, minimumLogicRate and maximumLogicRate, that can be used to ensure that your update() method is executed consistently, even in the face of very low or very high framerates.

Using minimumLogicRate

Conceptually minimumLogicRate is pretty simple. It specifies an amount of time (in miliseconds) that has to pass since the last update() call before it is called again. By default minimumLogicRate is set to 1, which means that your update() method is going to be called on every frame render. This may work well in testing on one particular system, but can make the game logic a bit difficult to get right on other machines. Older games often relied on the assumption that the rendering each frame took a fixed minimum amount of time. That's why on current computers a lot of older games don't work well, the computers are just too fast and the game logic updates too quickly.

By raising the value of minimumLogicRate you can prevent this problem. By setting it to a specific value (20 is a good initial choice) you can get consistent updates that allow your game logic to run in step with real time instead of depending on the framerate.

It's pretty simple to make this change. The GameContainer class has methods named setMinimumLogicRate() and getMinimumLogicRate(), that can be used to change this value. Do this in your main function and you can go about planning your game logic without worrying about the framerate. Well, mostly. One problem we still need to deal with is if the framerate drops to the point that our update() function isn't running as many times as it should. See maximumLogicRate below for that.

Using maximumLogicRate

Now that we have minimumLogicRate solving any logic consistency problems we might get from too high of a framerate, we need to tackle problems due to too low of one. This can be a source of some rather nasty bugs, especially because the framerate may not drop far enough on your computer or until you get into some of the more heavy-duty scenes. If you are relying on the logic being updated every twenty milliseconds and the framerate dips so that it happens every fifty you could run into problems.

To help handle this, Slick uses maximumLogicRate to allow you to run the update code multiple times in one time through the game loop. The GameContainer looks at maximumLogicRate every time through the game loop and compares it to the amount of time that has accrued since the last update() call. If that time exceeds maximumLogicRate then it divides the time from the last updated by maximumLogicRate and runs your update() method that many times. For instance if your maximumLogicRate is set to 20 and the last update() call happened 50 miliseconds ago the game will run your update code (50 / 20 = 2.5) twice.