System clock monitoring

[vidhi]

we have a java applet game that relies on a thread that ticks at 10n
miliseconds. Our problem is that we use the system clock time to see
the interval of ticks, and if a user manipulates the clock setting,
then we get erronous tick times.

Is there a way we can avoid this, or use the hardware clock , or some
solution where the user inteferenece will not disrupt the game ?

Thanks for all your suggestions,
-Vidhi.

 

[Skip]

we have a java applet game that relies on a thread that ticks at 10n
miliseconds. Our problem is that we use the system clock time to see
the interval of ticks, and if a user manipulates the clock setting,
then we get erronous tick times.

Is there a way we can avoid this, or use the hardware clock , or some
solution where the user inteferenece will not disrupt the game ?

In pseudocode:

if(Math.abs(expectedTime - currentTime) > x * 1000)
{
gameEngine.getTicker().makeCorrections();
}

But... who is changing the system-clock anyway, while playing a game... is
it worth the effort?

 

[Roedy Green]

we have a java applet game that relies on a thread that ticks at 10n
miliseconds. Our problem is that we use the system clock time to see
the interval of ticks, and if a user manipulates the clock setting,
then we get erronous tick times.

See http://mindprod.com/time.html
Use the nanotime feature to crosscheck.

 

[Skip]

See http://mindprod.com/time.html
Use the nanotime feature to crosscheck.

http://mindprod.com/jgloss/time.html

 

[Thomas Hawtin]

See http://mindprod.com/time.html
Use the nanotime feature to crosscheck.

On my Linux machine, I found that System.nanoTime changed with the
system clock.

On old versions of Windows the system clock runs in steps greater than
10 ms.

Java3D has an accurate clock, but that's probably not much use in an applet.

Tom Hawtin

 

[Roedy Green]

On my Linux machine, I found that System.nanoTime changed with the
system clock.

that should be considered a bug.

 

[zero]

we have a java applet game that relies on a thread that ticks at 10n

miliseconds. Our problem is that we use the system clock time to see
the interval of ticks, and if a user manipulates the clock setting,
then we get erronous tick times.

I've encountered the same problem with an applet connecting to a chess
server. If I remember correctly, I fixed it by using a javax.swing.Timer
object. The Timer object activates an ActionListener at specified time
intervals. This doesn't use the system clock (since it doesn't rely on the
actual time, only on time intervals), but instead uses hardware clock
ticks, so changing the system clock won't mess with the intervals.

It's been a while since I did this, and I'm not 100% sure it's correct, so
don't shoot me if I'm wrong. A little test could prove me wrong or right
though, so might be worth a try.

Zero

 

[Thomas Hawtin]

that should be considered a bug.

I thought so too. I reported it two months ago, but the incident hasn't
been through review yet.

You'd expect someone else to find it if the problem was widespread, but
no-one else appears to have reported it. I've upgraded from Redhat 9 to
Fedora Core 4, so it wouldn't appear to be down to a duff version of the
OS (unlike the dropped notifies). Perhaps it's the seven or so year old,
Compaq hardware.

Tom Hawtin