Rob Nugent wrote:
> 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.
I agree with you except for one thing; the timing issue is NOT a Java3D problem, it
is a Java problem.
It is important to differentiate the two if we hope to get it improved. Java3D
could add a better timer using some native code, it already uses native code to
render - OpenGL,DirectX, but the better solution is that the Java environment be
improved to do that.
--
__________________________________________________________
Shawn Kendall Full Sail Real World Education
Course Director 3300 University BLVD
Real Time 3D for Gaming Winter Park FL 32792
[EMAIL PROTECTED] http://www.fullsail.com
__________________________________________________________
===========================================================================
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".
