gcsaba2
Junior Devvie  
Hello world
|
 |
«
Posted
2006-09-10 13:33:09 » |
|
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?
|
|
|
|
gcsaba2
Junior Devvie  
Hello world
|
 |
«
Reply #1 - Posted
2006-09-10 13:36:56 » |
|
Never mind that, I see there's a System.currentTimeMillis() method 
|
|
|
|
Death33284
|
 |
«
Reply #2 - Posted
2006-09-10 16:24:34 » |
|
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
|
|
|
|
Games published by our own members! Check 'em out!
|
|
BloodRain
|
 |
«
Reply #3 - Posted
2006-09-10 19:03:53 » |
|
Never used System.nanoTime() , but System.currentTimeMillis() can be used like this : 1 2 3 4
| long t1=System.currentTimeMillis(); long t2=System.currentTimeMillis(); System.out.println("This took :" + (t2-t1)/1000f+" seconds. "); |
|
|
|
|
JAW
|
 |
«
Reply #4 - Posted
2006-09-13 18:00:57 » |
|
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
|
|
|
|
fletchergames
|
 |
«
Reply #5 - Posted
2006-09-14 03:37:31 » |
|
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).
|
|
|
|
gcsaba2
Junior Devvie  
Hello world
|
 |
«
Reply #6 - Posted
2006-09-14 09:08:04 » |
|
There's nothing wrong with System.nanoTime(). He just never used it. Plus I want compatibility with Java 1.4 
|
|
|
|
Ask_Hjorth_Larsen
Junior Devvie  
Java games rock!
|
 |
«
Reply #7 - Posted
2006-09-14 12:54:45 » |
|
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 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.
|
|
|
|
Markus_Persson
|
 |
«
Reply #8 - Posted
2006-09-14 13:42:17 » |
|
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.
|
|
|
|
appel
|
 |
«
Reply #9 - Posted
2006-09-14 13:49:15 » |
|
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.
|
|
|
|
Games published by our own members! Check 'em out!
|
|
pepijnve
Junior Devvie  
Java games rock!
|
 |
«
Reply #10 - Posted
2006-09-14 14:30:43 » |
|
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.
How did you solve this/work around it?
|
|
|
|
Markus_Persson
|
 |
«
Reply #11 - Posted
2006-09-14 14:34:20 » |
|
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)
|
|
|
|
Kova
|
 |
«
Reply #12 - Posted
2006-09-14 17:03:38 » |
|
how is nanoTime() getting it's time then? I though they were all (all timers) using time from BIOS (OS -> BIOS).
|
|
|
|
pepijnve
Junior Devvie  
Java games rock!
|
 |
«
Reply #13 - Posted
2006-09-15 08:41:05 » |
|
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?
|
|
|
|
oNyx
|
 |
«
Reply #14 - Posted
2006-09-15 09:33:21 » |
|
>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.
|
|
|
|
JAW
|
 |
«
Reply #15 - Posted
2006-09-17 10:06:23 » |
|
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
|
|
|
|
|