LWJGL 0.94 Released

[princec]

The hires timer in Util is not meant to time things that take more than a few seconds. The likelihood it'll wrap is great. That's the reason I cast it to an int. All it needs is the difference between the start value and the current value. It glitches when the time wraps.

If you're using hires timers, it's best to reset them frequently once you've timed what you want to time with them.

Cas

[EgonOlsen]

I'm not timing anything greater than one second. IMHO the problem is, that the getTime() in tick() is casted to an int, which doesn't work too well especially for systems with a high clockrate (because the getTime() values are rising very fast in that case). The current implementation works fine on my 1666Mhz machine, but it fails on the 3.2Ghz one right from the start. Maybe because the timer resolution doesn't fit into an int anymore and so the cast causes the timer to wrap around every second.

[princec]

Ah, could be.
Maybe I'll cast to a long and & it with 0x7FFFFFFFFFFFFFFF.

Cas

[EgonOlsen]

Ah, could be.
Maybe I'll cast to a long and & it with 0x7FFFFFFFFFFFFFFF.

That should help. For now, i've added the check for a wrap around to my Timer-class that sits on top of the LWJGL-Timer, the sun.misc.perf or the currentTimeMillis (whatever is available) and i did a test how many wraps do i get in 10 sec. Using the LWJGL timer and three timers, i got 17 wraps in these 10 sec. Using sun.misc.perf, i got none.

[princec]

I'll get the fix up in a couple of hours.

Cas

[willdenniss]

The Timer class is most handy, thank you.

It was already mentioned in this thread, but wouldn't it be possible for the wrapping to occure even sooner than one second if using an insanely high resolution timer?  Does LWJGL protect against this with a limit to the timer resolution?

Sometimes it is desirable to use the Timer for longer peroids of time than can be supported by storing the time in seconds as a float (and as of this version, storing the time in an int as well).  I was going to suggest having a second Timer ("TimerDouble?", "LongTimer"?) which stores the time in seconds as a double to provide higher accuracy and longer potential running time.  It is a rather trivial thing to add, I was just going to make my own for my use, but I thought it might be good to have in the library as well.  Obviously this class would need to store the time as a long.

I think there is definitally a use case to have two timers -- one for short <1 sec use, and one suitable for timing much larger events.

BTW -- Thanks for the new release!!!

Will.

[oNyx]

Yay!

Just that. Yay! :>

[Funkapotamus]

DevIL huh?

STOP ADDING NEW FEATURES!!

I'm taking two steps backwards for every one step forward  By the time I get familliar with the newest version and start making headway with my game, another version comes out with new features to play around with!  I'll never get anything done at this rate!

Hehe, seriously though guys, nice job!  Thank you!

[Matzon]

The great thing about any of our feature creep is that it is componentized - if you don't want to use fmod or devil, just ignore the dll and jar. LWJGL will happily funtion without. The same goes for the lwjgl_util.jar and lwjgl_test.jar, if you don't use them, just ignore them.

[EgonOlsen]

I'll get the fix up in a couple of hours.

Anything new about this topic? I've modified my Timer-class, so that it uses the good old currentTimeMillis for everything but sub-second timing (which is fine...you don't need the hires accuracy anyway in that cases) and the wrap around doesn't hurt me that much anymore, but nonetheless, i would love to see this fixed. The LWJGL-timer should behave at least as good as the inofficial Sun timer does, IMHO.