Tell me more ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.
up vote 3 down vote favorite
2

So far I've always used a time granularity of 1 msec (that's it, 1 millisecond is the atomic time unit).

I'm wondering if this is always fine, or if for some cases (some specific games, game components or platforms) it would be suggested to have a more accurate time unit (on the order of microseconds or, I don't know, hundreds of microseconds).

share|improve this question
You would be struggling to get that kind of accuracy. There's no gurantee you can run by the millisecond on desktop platforms, IIRC. – The Communist Duck Dec 23 '10 at 11:49
Actually newer systems (real time OSes, many BSDs and patched Linux kernels) are even starting to support nanoseconds (although they cannot be very accurate). The time granularity offered by any Linux system is on the order of microseconds (10 msecs at most, IIRC). – peoro Dec 23 '10 at 12:44
10usec is the usual measurement given for modern Linux gettimeofday accuracy, but that function is subject to clock drift and user changes, so it's not appropriate for games anyway. I've seen clock_gettime be accurate to within several hundred nanoseconds usually, which is approaching the hardware limit. – Joe Wreschnig Dec 23 '10 at 12:48

2 Answers

up vote 6 down vote accepted

There's really two different questions here.

First is, how accurately can I measure the time? and the answer is incredibly accurately.

All modern CPUs (like, ~2000 onwards) come with high-resolution timers. On Windows, QueryPerformanceCounter is used to read these; on Linux and other POSIX systems, clock_gettime; on Mac OS X you can use mach_absolute_time or this wrapper that provides a basic POSIX-like clock_gettime wrapper around mach_absolute time.

These timers provide counters measured in nanoseconds, and the practical resolution is usually measured in microseconds. These clocks are also monotonic, meaning they should not go backwards, even if the user adjusts their clock or you're on a multicore CPU system, although there have been buggy BIOSs that caused this for some chips.

The second question is how quickly can I respond to events? and the answer here is much more depressing.

PC operating systems use preemptive multitasking, which means how much time your program gets is completely under the purview of the OS. When you sleep(10ms), that's a suggestion to the OS. It's rarely perfect, but usually it'll do its best, and you'll wake up sometime within the next 9.9 to 10.1 milliseconds. Sometimes though, it might be 15. Sometimes, if the system is under heavy load, it might be 10000. If an interrupt or signal occurs, it might be 1ms. This is why we have to jump through hoops to get truly stable timesteps in games.

Just knowing the time within 1ms precision? No problem. But relying on game logic that requires more precision than 1ms? That's a tricky business, and probably not appropriate for anything today.

share|improve this answer
There's a third question to consider here: how long can lag times realistically be before the player notices? Generally what matters to most players isn't the clock speed, so much as the framerate. – Ian Schreiber Dec 23 '10 at 20:20
Ian: What usually ends up being a problem is frequency interference from e.g. a 60Hz display update and a 29Hz game logic update, which usually is an issue of precision, either in the clock used or the sleep interval. Once you have dealt with that (via interpolation or whatever), anything ~20fps and up feels "okay". – Joe Wreschnig Dec 23 '10 at 22:41
Ian: The other common problem - probably what you're calling "lag" - is due to double/triple buffering patterns on display and input, and is really outside the scope of this question. – Joe Wreschnig Dec 23 '10 at 22:42
Never sleep. You should busy wait. – bobobobo Dec 25 '10 at 10:49
1  
Busy waiting burns CPU like crazy and most games are GPU bound, not CPU bound. Sleeping until slightly before you want and then busy waiting up to that point can be acceptable, but busy waiting damages hardware, wastes electricity, makes other applications unusable, and still doesn't stop the OS from forcing you into the background. – Joe Wreschnig Dec 25 '10 at 12:58
up vote -1 down vote

It depends.

As far as I'm concerned a game has a time unit of 16.66667ms (1/60 seconds).

Other than synchronizing framerate with the display, I don't need a concept of real-time except how much to idle at the end of a frame before rendering the next one.

I use a high performance counter there though (and microseconds!), because if there only is 1.45 ms left in the frame before the next one should be rendered, I don't want it to wait 2ms!

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.