I use GageTimer for my game:
http://java.dnsalias.com
However it seems to take much CPU, can anything be done about that?
It doesn’t really matter if it takes a lot of CPU so long as it does so at a low priority. I.e. any other useful work will take the CPU from it. I think that is how it works, I’ve never used it.
Thats it exactly, it shows as 100% CPU but if something else pops up then the timer gets pushed down. I think this is a windows only behaviour.
There was quite a long discussion about this on these forums, can’t find it right now tho…
Kev
Thx. Anything in java 1.5 that will help timing issues?
Yep, the “hidden” native timer is meant to made formal in 1.5.
Kev
In 1.5 use System.nanoTime()
“Hidden” as in unsupported?
No. “Hidden” meaning that it’s actually a part of the current JDK release, but it’s pushed off somewhere in an undocumented class. With the 1.5 release the “nanoTime()” method will be moved into the “standard”, fully-documented portion of the Java API. If you can wait a few months for the 1.5 JDK (and unless you’re very close to a game release, then you can probably wait), then I’d would just wait for it.
Actually I think the answer to unsupported is “yes”
it is in a package that Sun explicitly claims is unsupported. Though it appears that most 1.4.2 implementations will have it you should still protect your code in case the method is not found and fall back to System.currentTimeMillis or something.
Are we talking about the stuff in sun.misc.Perf?
That’s what I was talking about in terms of the “unsupported” timer.
Uh…hidden…unsupported…uh…oops!
Whatever’s in sun.misc.Perf it doesnt seem to use a native timer, because over time it strays away compared to GAGE.
How do you know it’s not the GAGE timer that strays away?
Because Gage and Perf is running on a server and I’m connecting to it with game clients. All game clients work with Gage, all clients complain of straying with Perf. Whatever Gage is doing, its not the same thing Perf is doing.
[quote]Because Gage and Perf is running on a server and I’m connecting to it with game clients. All game clients work with Gage, all clients complain of straying with Perf. Whatever Gage is doing, its not the same thing Perf is doing.
[/quote]
I just love it when a plan comes together. 
BTW, are you using Thread.sleep() with the Perf timer? If you are, that’s probably the source of drift. GAGETimer uses Thread.yield(). It makes the CPU run flat out, but it doesn’t drift and other programs still get their CPU.
BTW, if anyone’s seen Kommi, tell him that GAGETimer can and will overflow. In the year 300,001,979 A.D. that is. ;D 
That is true. Perf and Gage mesures time in two completely different ways. So there will be relative drift unless they are both drifting by the same amount. To find out wich method is the best you would have to compare against an external clock that you know are accurate. If you use System.currentTimeMillis() to measure the drift then Gage will seem to be accurate because it uses System.currentTimeMillis() to calculate it’s time.
The Perf timer uses a counter in the cpu that is incremented every clock cycle. This is divided by a “cycles per second” or frequency. So the accurace of it’s timing depends on this value. Not sure how correct this value is though.
[quote]That is true. Perf and Gage mesures time in two completely different ways. So there will be relative drift unless they are both drifting by the same amount. To find out wich method is the best you would have to compare against an external clock that you know are accurate. If you use System.currentTimeMillis() to measure the drift then Gage will seem to be accurate because it uses System.currentTimeMillis() to calculate it’s time.
[/quote]
You might want to recheck that. Under Windows, GAGE uses the Windows Hi-RES timer. It will be accurate as long as you’re using the GAGE sleep functions. There’s only one instance that it will drift. (see below)
[quote]The Perf timer uses a counter in the cpu that is incremented every clock cycle. This is divided by a “cycles per second” or frequency. So the accurace of it’s timing depends on this value. Not sure how correct this value is though.
[/quote]
I was under the impression that the Perf timer also used the Windows Hi-Res timer. For reasons I can’t remember right now, clocks based on the CPU will drift and have to be constantly re-calibrated. That’s why nearly everyone settles with the comparably low resolution of the hi-res timer. However, there is a circumstance where every windows timer can drift!
When Sun was doing the implementation of Thread.sleep(), they had a problem with the windows scheduler having a resolution no lower than 5 milliseconds. To fix this, they added some sort of timer hack that would allow the sleep() method to approach 1ms resolution. The only problem is that the hack can accelerate the system clock! As a result, constant calls to Thread.sleep() with a time of less than 5ms may result in clock drift.
[Quote]BTW, are you using Thread.sleep() with the Perf timer?
[/quote]
Yea, I’m using Thread.sleep() and the problems occur with windows2000.
I’d say that’s your problem. I checked around and found the original bug report on the issue. It seems that it’s worse than I remember. 10ms or less of sleep time will cause drift. There is a command line flag that can be used as a workaround, but it’s not a permanent solution. As a result, the end message is: avoid Thread.sleep() for short sleep periods!