This whole issue has been annoying me for
some time now. My understanding is also that the
multimedia timers in javax.media.Manager.getSystemTimeBase
also suffer from a similar quantization (although it's been a
while since I tried them myself). This means that if each
of my frame time is, say a consistent 13ms on WinNT, then it gets
reported by the System.currentTimeMillis() as
10, 10,10, 20,10,10 ...
Leading to visibly jerky animation, since I calculate how far to
move each object each frame, based on its speed.
I am currently running with a native library on WinNT that does
nothing but call QueryPerformanceFrequency/QueryPerformanceCounter
to work out how long the last frame took.
If I could put in one Request For Enhancement for the next Java3D it would be
for a timer that returns the best resolution the underlying platform can provide.
Rob
Joerg 'Herkules' Plewe wrote:
> >
> > 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".
--
Rob Nugent
Development Manager
PeerLogic
[EMAIL PROTECTED]
http://www.peerlogic.com
Tel: +44 (0) 1489 585503
Fax: +44 (0) 1489 881363
===========================================================================
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".
