>
> First, on Win9x and NT, System.currentTimeMillis() does not have
> that good of
> accuracy. For example, if you were to print out
> System.currentTimeMillis() in
> a loop, the values will jump at approximately 5ms intervals. i.e.
>
> 1000...1000....1000....1005....1005....1005...1011....1011....
This in on NT. Win98 has a much worse resolution of about 50ms.
Linux OTOH has 1ms. Same hardware.
But 50ms is too bad for a fluent 25fps animation. I had the same problem
with a little 2D game. The only solution there seems to be to use averages.
But this again works only if frametimes are coherent, e.g. do not change
very much from frame to frame.
> Something like that. As I understand it, this is a Windows
> problem because of
> the way it handles multiprocessing and multithreading. Windows
> is not meant to
> be a real-time OS, anyway.
No no. Win98 has HIGHLY exacts timing functions (QueryPerformanceCounter)
that are typically used in games. So it is due to a bad implementation
inside Java.
> BTW, most UNIX OSes will give ~1-2ms accuracy,
> which is not must better when you need ~16.7ms to do 60 fps.
> Also, sleep() suffers from the same problem. Sleep(20) is not
> going to be 20ms
> that often.
IMHO Sleep() is meant to say 'sleep at least'. There should be no guarantee
for a re-schedule in the right moment. Java is not a realtime thing (oh
yeah!).
- J
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
