Simulations Part 1: Timing and Interpolation

Hello and welcome to Simulations 101. This hopefully should clear up the why’s and how’s of making things happen at the correct time and speed in a video game / simulation. This is an abstract tutorial in the category of general game programming. Any techniques explained in this ‘Simulations’ Series will generally be organized from easy/obvious/inefficient to hard/not-so-obvious/efficient.  Unless there are special-considerations for specific languages, algorithms will be presented in pseudo-code that people familiar with java and c++ can follow.

To start, some definitions:

High Resolution: this means that small increments of time can be discerned. Usually in games this means around the tens of milliseconds to nanoseconds range when talking about video games.

Low Resolution: this means that only large increments of time can be measured. Anything above one second (minutes, hours, months, years, centuries… etc.) is considered low resolution for a video game

Refresh rate: how many times a monitor or LCD is refreshed. Almost certainly going to be between 60 -85 Hz (60- 85 times a second).

Frame rate: how many times the image for the game is changed. Your screen will always be refreshed 60 times a second but if your game takes half a second (0.5 seconds) to compute player positions, collision,  awesome particle effects, and then display the changes; your frame rate is going to be 2 (the screen will be refreshed 30 times with the same image because your game hasn’t gotten around to changing the memory where your video is stored but spent time doing other game logic stuff).

Game-Speed / Time Step: Game speed is totally different concept than fps or refresh although they can be dependant on one another. A constant game-speed is desired for anyone who plays your video game so that you can design a fair game with predictable results.  All the concepts presented here are basically to achieve a constant rate for gameplay despite varying cpu and fps changes. A time step is just the time that goes by in any simulation – Sometimes there are multiple time steps that happen in a frame to increase the accuracy of the simulation

Ok, hopefully you understand most of that. Next, here is a brief explanation of the three main timing techniques used for games

Technique #1 –  Non-Stop Game-Loop with loop delays

This is by far the most used way to time video games on older generation video game consoles and computers – DON’T DO IT!!!. Rendering the graphics and doing game logic were developed with particular machines with a particular cpu speed and with the expectation that the video game will not have full control of all computing resources and will not share it.

while(!ending)
{
    runGame(); //updates your game status and simulation
    drawGame(); //draws everything in their appropriate positions on the screen
}
void runGame()
{
    float unit = 4.5;
    xTransformSprite(unit);
}

In the main game-loop, which is running constantly, a tiny loop that does nothing inside of it but waste time by counting to some constant, is tweaked by the programmer (sometimes user defined) and is used to delay for a certain period until the program updates at the desired frame rate.

As you can see, downsides to this approach include a barrier of putting hard-coded values in your code, that when your program take longer than you anticipated for the game-loop, all those values have to be accommodated for a slower frame rate.

Technique #2 – Callbacks and Interrupts

This process is actually still very common and is very similar to the previous technique except for 2 small differences. The first is that instead of using a loop, it requests the Operating System to wait for a specified period of time and then come back. The other difference and advantage is that this gives other programs a chance to run.

a call-back for a game loop might look something like this using Allegro

while(!ending)
{
    runGame(); //updates your game status and simulation
    drawGame(); //draws everything in their appropriate positions on the screen
    rest(50); // tells the system to take back control and return in 50 milliseconds
}
void runGame()
{
    float unit = 4.5;
    xTransformSprite(unit);
}

For handheld systems, hardware interrupts are a way of performing this exact task they are similar to callbacks except they are a very reliable way of timing your game. On the Game boy advance, for example, all the game logic and drawing has to be done in between the screen refresh, and it is called from the beginning every time the screen is rendered. On the GBA the screen Refresh, FPS and Game-loop are all synchronized. As long as you have complete control of the hardware as in the case of the GBA, this method is a very suitable way to time your game. Even If you don’t have control over the hardware, no-one will probably get on your case if you stick with this method if your game is fairly simple.

Technique #3 – Delta Time

This is where things start to get hairy. Depending on the language you use and the OS, getting current system time at a high resolution can be very different. One way to solve this is to use a High Resolution Timer Library where someone has done all the hard work.

The basic idea is that all systems are generally guaranteed to provide accurate time up to the second but no more. Access to the OS’s API probably reveals functions that aren’t very friendly to timing your games in tenths or hundredths of a second but probably in “Clock Ticks”,  and may even provide a clock ticks per second function. Although the thought of learning windows programming may be strike fear in the novice programmer, like I said before, there are other options: Java and C# have pretty good timer functions. For C++, there are many game and general utility libraries also provide a high-resolution timer function that is easy to use in game. The following is usually how it’s done if you get your time in milliseconds -

int last = System.getTimeMillisecond(); //our timing library function in milliseconds
int current = last;
while(!ending)
{
    runGame(current – last); //updates your game status and simulation
    drawGame(); //draws everything in their appropriate positions on the screen
    last = current;
    current = System.getTimeMillisecond();
}
void runGame(int delta)
{
    float secondsSinceLastFrame = delta / 1000.0;
    float unit = 4.5;
    xTransformSpriteUnitsPerSecond(unit *secondsSinceLastFrame);
}

And that’s it! I think Koray has done some Windows API timing so well see if that stuff makes it in here.

This is just a rough draft so please email me of missing/wrong information or what you would want in simulations 102 (particles anyone?).