Timer's in Java suck

[K.I.L.E.R]

I've used NanoTime which I measured against LWJGL's timer and my results were that Java 5's nano timer is a bit better than LWJGL's timer.

Regardless, every so often I have timer farts with both LWJGL and nanotime.

I have been testing the use of timers in games and I made a GL game Pong to try out some timer techniques.

Needless to say I succeeded.

BUT...

If the game has a timer fart then problems occur.
Such as the ball going through a Padel for that one instant but it still does collision detection(thankfully) and then rebounds.

Also the timers tend to sometimes feel really fast and then slow down again(WTF??) to their normal pace for a periodic moment.

On that note sometimes my graphical movements can get jerky.

It's unpredictable. All these things occuring are unpredictable.

Needless to say Java timers result in WTF.
Anyone have a solution, besides moving to C#/C++/C/ASM?

FPS: 2543fps.
This is in a 640x480 32bpp windowed mode.

FPS: 1964fps.
This is in 800x600 32bpp fullscreen mode.

[gregorypierce]

Well I don't know how Sun's timer is implemented under the covers but I would imagine it to be a native OS call the same way that LWJGLs timer is structured. There isn't very much 'java' in LWJGLs timer at all as its getting the platforms highest resolution timer via the OS.

Periodic slowdowns or changes in performance are, in my experience, a product of the OS or the JVM doing some work.

[princec]

Actually I get the quick-slow-quick-slow problem too, and it turns out it's because of the HT chip in my lappy. The hires timer simply gets confused by the hires timer and ticks at different rates. The only solution might be to query the resolution far more frequently than we currently do. Maybe every tick.

Cas

[K.I.L.E.R]

It is being done every tick.
That's why I noted this as a problem.

[princec]

Shit. Perhaps it's got to be queried every call to getTime()!? Or perhaps once only and never again after?

Cas