System clock monitoring

V

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.
 
S

Skip

vidhi said:
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?
 
R

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.
 
T

Thomas Hawtin

Roedy said:
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
 
Z

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
 
T

Thomas Hawtin

Roedy said:
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top