Animation Timing
This message brought to you by the association for cross hardware compatibility (ACHC).
As demo writers we often ignore animation as unnessesary but when we use it, its usually a dirty hack job. I can admit that up until last year I too was guilty of this infraction but it must stop. I can’t count the number of demos I have downloaded that end up spinning madly due to a “rotation++” style animation in the display function. Frame rate dependent animation was alright a couple of years ago when the difference in speed between cards was minimal. Today, however, with the exponential growth of graphics technology your animation could be too fast in less than a year.
The most annoying thing is that it is so easy to implement simple timing control that laziness can’t even be used as an excuse. For the truly lazy, however, I will provide some example code in Listing 1 (GLUT) and Listing 2 (Win32) that you can cut and paste into your applications.
int tlast, tcur, nframes = 0;
double tdiff;
void draw()
{
// Update Timing
nframes++;
tlast = tcur;
tcur = glutGet(GLUT_ELAPSED_TIME);
tdiff = (tcur – tlast) / 1000.0;
…
}
int main (int argc, char **argv)
{
…
tcur = glutGet(GLUT_ELAPSED_TIME);
glutMainLoop();
}
Listing 1. OpenGL/GLUT timing mechanism
int tlast, tcur, nframes = 0;
double tdiff;
void draw()
{
// Update Timing
nframes++;
tlast = tcur;
tcur = timeGetTime();
tdiff = (tcur – tlast) / 1000.0;
…
}
int main (int argc, char **argv)
{
timeBeginPeriod(1);
…
tcur = timeGetTime();
gameLoop();
timeEndPeriod(1);
}
Listing 2. DirectX/Win32 timing mechanism
Once you have this code in your demo skeleton you are ready to animate. When you want to move something first create a velocity vector which constitutes how much it moves per second. Then during each frame you multiply the velocity vector by tdiff and you add it to the objects position. It now has moved a fraction of the velocity based on what fraction of a second passed between frames.
In addition to this I believe it is important for demo writers to try moving away from frames per second (FPS) as a metric. This article gives a good explanation of why FPS is very misleading and suggests using instead milliseconds per frame (MPF) or frame time. We are always looking for that holy grail of 60 frame per second however since FPS is not linear its really hard to judge from the current frame rate how to proceed with optimizations, etc. When using frame time it is linear so 16.666667 MPF is 60 FPS and you can work from there.