Hi there !
I heard some people use native Timers through the JNI to achieve nano-resolution with windows-platforms.
Does anyone know how to do this, or where to find a tutorial about it ?
I never used JNI, so i would be very glad if someone knows.
mbw
Java Pro had an article about using the high res timer for windows (along with the code needed):
http://www.fawcette.com/archives/magazines/javapro/
Entitled: Time for Java by a chap called Kevin T. Manley, Dated 2001/08.
Try:
http://www.fawcette.com/archives/listissue.asp?pubID=3&MagIssueId=407#
Or search the old forum for other links & tips.
Hope this helps!
Woz.
P.S.
Why is this post inserting a space between 40 & 7# ???
The link still works though.
Or just go grab the Lightweight Java Game Library:
http://java-game-lib.sourceforge.net/
Which has one in there. Either pluck the bits of source code out just to do the hires timer, or marvel at all the other useful things you can do and use the lot ;D
If you’re using JNI anyway, may as well go the whole hog, eh?
Cas 
… or look at the hires timer from the latest Java3D release.
I assume it relies on QueryPerformanceCounter() and ticks VERY fast! I’ve not measured it yet, but I think it’s by far good enough for every gaming issue.
I expect this timer to be part of the next J2SE, so your effort will not be wasted.
Anyone care to comment on a Mac OS X version of any of this?
You give me that, so that I can have a mac and windows hi-res timer, I’ll be the happiest person. ;D
If it can’t be done, I’d really like to know why. I have searched for anyone using JNI on the Mac, and nothing.
I just grabbed the Lightweight Java Game Library (
http://java-game-lib.sourceforge.net/ ) and meassured the granularity of its HiresTimer, and it seems to have an granularity of 0.01 ms and less, whereas System.currentTimeMillies has a granularity of 50 ms on my machine (Win98, K6-2 333MHz).
Is this possible? I can’t believe it!
The hires timer in Windows, and indeed any x86 based machine, is actually a clock-cycle ticker direct from the CPU. Its granularity can be down to 1,000,000,000ths of a second. By contrast the O/S thread scheduler and messaging system is very vague, relying on the fairly low resolution of the system clock.
On MacOS there should be an equivalent hires timer but it’s up to Gregory to make the port happen. Of course he can’t yet, because he hasn’t got a 1.4.x Mac port to play with. But it will rock.
And we still have no takers to port the LWJGL to Linux. C’mon, surely not difficult?
Cas
Thanks for the support guys ! ;D
[quote]I just grabbed the Lightweight Java Game Library (
http://java-game-lib.sourceforge.net/ ) and meassured the granularity of its HiresTimer, and it seems to have an granularity of 0.01 ms and less, whereas System.currentTimeMillies has a granularity of 50 ms on my machine (Win98, K6-2 333MHz).
Is this possible? I can’t believe it!
[/quote]
Karnak the great says…
Youa re running WIin95, Win 98 or Win ME.
And yes thats correct. The Win32 call used by System.currentTimeMillis() is very inaccurate on those systems.
Highres tiemrs either call the cloick in the multi-media extensions DLL which is much faster or go directly to the CPU ticks.
Cas,
I’d love to do it myself. There are two problems stopping me:
don’t own a Mac yet. I can get 1.4.1, but I have nothing to install it on. :’(
I have ZERO programming experience on the Mac. So even if I could write the JNI header and such (which I am sure I could) I wouldn’t have the faintest notion of what to attach two.
Sorry, I wish I could be more help there.
Just found something that could be useful.
Take a look into the MidiSystem and get hold od an MidiDevice through the MidiDevice.Info class. In it yuo’ll have getMicrosecondPosition().
here’s what it says:
public long getMicrosecondPosition()
Obtains the current time-stamp of the device, in microseconds. If a device supports time-stamps, it should start counting at 0 when the device is opened and continue incrementing its time-stamp in microseconds until the device is closed. If it does not support time-stamps, it should always return -1.
Returns:
the current time-stamp of the device in microseconds, or -1 if time-stamping is not supported by the device.
anyone tried it?