Game Clock Precision

Question

I'm reading a fantastic article about game timer precision and here is a quote about 2/3 of the way into the article:

If you start your game clock at about 4 billion (more precisely 2^32, or any large power of two) then your exponent, and hence your precision, will remain constant for the next ~4 billion seconds, or ~136 years.

He doesn't give a concrete example of this though. Does this mean I would want to add 2^32 to the game clock value that I store at the beginning of each frame? Or is there a way to actually set the clock in Windows so that the numbers start at 2^32?

Answer 1

TL;DR The author is not suggesting you implement this in your game. He's telling you that the precision will be slow changing, but bad.

This means the float you're using to track your game time would start at 2^32. Because setting the number that large to start with, whatever you add on to it in the next 136 years, won't change the exponent.

Though, the precision will remain constant, it doesn't mean it's better. The precision gets worse the larger the number. Starting with a large number just means that the precision won't change over the life of the counter, but the precision is worse than starting with a small number. If you started at 0 the exponent would change frequently at first, meaning the precision changes frequently.

Concrete example:

float twoToThirtyTwo = 4294967296;
float game_time_elapsed = twoToThirtyTwo;

float getTimeElapsed() {
     return game_time_elapsed - twoToThirtyTwo;
 }

I believe overall the article is suggesting using floats for time deltas (short/small time spans) and using ints or longs for time elapsed (long/large time spans).

---

The author suggests a change to the code above to make it usable, since it's currently an example of how you can have constant bad precision. Change to a double:

double twoToThirtyTwo = 4294967296;
double game_time_elapsed = twoToThirtyTwo;

double getTimeElapsed() {
     return game_time_elapsed - twoToThirtyTwo;
 }

That code should give a constant good precision (around 1 microsecond) for a long time.

Answer 2

Most games have a function that calculates the current time -- perhaps using QueryPerformanceCounter(), perhaps using GetTickCount64(), perhaps using something else. Normally this function is designed so that it initially returns zero, and then gradually returns larger numbers.

What the author is saying (and I can be definitive about this because I am the author) is:

• The first value returned should be 2^32 instead of zero and it should smoothly increment from there.
• The return value should be a double, not a float.
• Comments on the article itself instead of here would be better.

Answer 3

Here's another discussion on game timer implementation and accuracy, complete with source code, that may help you with your game timer requirements.

Cygnon's Blog: Game Programming Adventures

Answer 4

From Tom Forsythe's article (which is linked from Bruce's article, but not really discussed:

One "solution" [to floating point precision problems] is to turn on double precision, because then you get more bits. Yeah, but you've just shuffled the problem around. Doubles have exactly the same weaknesses [as floats] - all you've done is shuffle the problems into a corner, stuck your fingers in your ears and yelled "lalalalalala". They'll still come back to bite you, and because it's double precision, it'll be even rarer and even harder to track down. And they're slower on most machines, so you've hurt your execution speed.

(my clarifications in bold)

Precision problems make floats and doubles just a fundamentally bad choice for representing absolute time. This is why Windows doesn't use them to represent absolute time. This is why OS X doesn't use them to represent absolute time. This is why Linux, BSD, Solaris, and every other OS under the sun doesn't use them to represent absolute time.

If you're storing the absolute game time, you really are better off using fixed point integers. Reliable, repeatable, and with consistent precision across their whole range. "Because I like seconds" is a pretty feeble reason to move to imprecise and error-prone storage for something as critical to a game as its internal clock, if you ask me.