Timing in java and networking

[Absolution]

Due to the problem of timing in java, is it not difficult to keep your games in sync.?  Say, one client is using win2k and has 10ms resolution, while another is using 98 and has 15ms resolution.  It's pretty much impossible to run a real-time game and keep the game in sync. on both computers is it not (assuming you want to just send input commands)?  This probably isn't a problem in the latest version since a higher res. timer is available, but what about older applets and such?

[swpalmer]

Search for GAGE Timer...  or check the WIKI (link at the top of this page).  This problem has been noted here many times already and the GAGE timer is probably as good as any other solution out there.  (I haven't used it myself)

[Herkules]

Long time timer accuracy and timer resolution do not neccesarily interfere.

When I used to head for currentTimeMillis() in a prototype where it's resolution was sufficient, I found that also the absolute values show a significant drift on different machines. The values can drift by multiple seconds during several minutes of play.

So I use to resynchronize clocks frequently (every minute or so). For my clock sync is the only natural point where I can measure the ping value, I use it to give the user some feedback about the current quality of his connection.

Games published by our own members! Check 'em out!

[blahblahblahh]

Due to the problem of timing in java, is it not difficult to keep your games in sync.?

Sync'ing distributed clocks is much much harder than the problems of pre-1.5 inconsistencies in java's timing granularity. Distributed time is quite easy if you know how (look up research on vector-time/vector-clocks for a start), which works by not using clocks at all.

Short answer: don't bother with your PC's local clock for game-synch. Use something more high-level (in general), like key-frames. Obviously, it's non-trivial choosing what to use, and depends very much on the architecture of your game.

[Herkules]

From your hint, I found

http://www.vs.inf.ethz.ch/publ/papers/logtime.pdf

which helps to categorize, what kind of time actually is needed.

For sure there's a difference between systems that can talk in 'frames' (e.g. RTS) and one that seems to be continous in time (like a flightsim).

I always try to live with 'roughly synced clocks', so that I can use timestamps that mean at least something, if not the true time. But I admit that it is hard to deal with that.
Object may die remote before I see that I hit them and so on.

Really difficult. For games, maybe its a good strategy to cheat and fake. Taking time into account more or less, depending on what looks better in a particular case

[blahblahblahh]

From your hint, I found

http://www.vs.inf.ethz.ch/publ/papers/logtime.pdf

Thanks, that's quite a good PDF on the subject.

[Jeff]

There are a number of open Java sntp implementations out there.  Thats what Ive used to synchronize system time and deal with drifts.

Micro-timing is somewhat pointless on the intern et where latencies can range for a few hundred ms all the way up to 6 or so seconds for an analog modem retrain.

For timing within an app though, you can use GAGE or the new nanosecond timer in JDK1.5

[Mark Thornton]

Of course the granularity of the new nanoTime method is still likely to vary from system to system even if the operating system is the same.

[Jeff]

Yes, but it is gauranteed to be the best possible  on the platform.

So its as good as you coudl do from native.

[Mark Thornton]

Yes, but it is gauranteed to be the best possible  on the platform.

So its as good as you coudl do from native.

I have some native code which reads the Pentium clock count register; that is the best possible on this machine but I'm not sure that nanoTime is doing that.

Games published by our own members! Check 'em out!

[Jeff]

By definition if it is not producing as accurate a time as you are then its a bug.  Report it and give your native code sample.

That was the reason the definition was written the way it was.

[tom]

The "Pentium clock count register" has some issues that may make it unfit to be used by nanoTime. First of all ticks per second has to be mesured using another timer. Also the number of actuall ticks per second can vary. Apparently some computers may dynamicly change the mhz. In wich case you can't use it to mesure time.

[Mark Thornton]

In wich case you can't use it to mesure time.

I only use it for evaluating performance where counting clocks is actually an advantage --- it is independent of the clock frequency. Apart from directly reading the clock counter register, the next best 'timer' on Windows is the performance counter api. However on dual processor machines this also returns the clock count. I don't know if the frequency values returned by this api vary on machines with variable clock frequencies (not common on true duals, but more likely on a hyperthreaded machine).