I need a timer for my game to always know the current time. I think that doing new Date().getTime() every millisecond would be a very bad solution, so is there a better way to do this?
Never mind that, I see there’s a System.currentTimeMillis() method :-[
If you are using java 1.5+ I would recommend using System.nanoTime() instead, but if you are pre 1.5 look for a different hires timer
Never used System.nanoTime() , but System.currentTimeMillis() can be used like this :
long t1=System.currentTimeMillis();
//some time-eater code :)
long t2=System.currentTimeMillis();
System.out.println("This took :" + (t2-t1)/1000f+" seconds. ");
Whats bad with nanoTime? I thought currentTimeMillis is bad…
Well for windows, currentTimeMillis only goes in steps of 50 ms.
So if you use the source you posted, I would get time passed: 0, 0, 50, 50, 50, 100, 100, 150… if you count time passed since beginning.
-JAW
There’s nothing wrong with System.nanoTime(). He just never used it.
One issue is that it doesn’t store the time since a given moment. Instead, it stores the time since some arbitrary time chosen when the JVM starts. The only problem with this is that you can’t use System.nanoTime() to figure out what the current date is. Use System.nanoTime() for timing stuff and System.currentTimeMillis() for finding out how long it’s been since January 1, 1970 (I believe that’s the date it starts at).
Plus I want compatibility with Java 1.4 
[quote]Whats bad with nanoTime? I thought currentTimeMillis is bad…
Well for windows, currentTimeMillis only goes in steps of 50 ms.
So if you use the source you posted, I would get time passed: 0, 0, 50, 50, 50, 100, 100, 150… if you count time passed since beginning.
-JAW
[/quote]
That would have to be an older version of Windows. I have observed a figure of around 10 ms on Windows XP, and it is said that on Windows 98 it degrades to around 35 which is reasonably close to the figure you quoted.
Nanotime works HORRIBLE on dual core systems… like my computer at home.
Sometimes it gets the time from core0… sometimes from core1… if they start drifting apart, you’ll have time updates that go BACKWARDS in time.
omg 
thanks for the heads-up.
How did you solve this/work around it?
In wurm, we use gagetimer (and java 1.4).
For the mario game, which uses nanotimer, I added a small check to see if the time ever goes backwards… if it does, it starts using the average passed time per frame to advance the time, instead of the actual passed time.
That’s not a very good solution, though, as it’ll make the game run too slow for a short time if the fps suddenly drops (like if a large number of sprites spawn at once)
how is nanoTime() getting it’s time then? I though they were all (all timers) using time from BIOS (OS -> BIOS).
I always thought most high precision timers (on win32) use QueryPerformanceCounter. The msdn documentation states that due to bios or hal bugs there might be issues on multi processor systems. Does anyone know if nanoTime or gage timer use a different timing mechanism or if they both suffer from the same issue?
I always thought most high precision timers (on win32) use QueryPerformanceCounter.
Yes, its the one with the highest resolution.
However, lwjgl switched over to TGT (timegettime) with 1msec res on windows and just currentTimeMillis over at mac/linux (1msec res there anyways). A 1msec res is good enough for games so it seems. All games with quake/doom engine are using a 1msec res timer, too.
I once searched for different timers. They are either some workaround that calculates an average time based on a couple of measures in the past. That works well enough with an overall constant framerate but when the framerate drops it goes a little off. The alternative I found were native Timers, usually dlls.
I didnt hear about using Time and Date methods, but it sounds like an idea. Does this work? Which class, which method?
-JAW