0.94 has been released here (https://sourceforge.net/project/showfiles.php?group_id=58488)
This is mainly a bugfix release, however it does include:
* Mac OS X port, made possible using your donation money
* Devil support (win32 initially)
* lots of other stuff I always remember... - bloody devs, never sending me any changelogs :p
This release does not contain any noteworthy changes to the fmod port, since another binding is in the works - due to be released in a week or two - depending on the quality and license of that binding we'll decide lwjgl's fmod bindings future.
Note For now:
* Fmod is win32 & linux
* Devil is win32
Still working on enabling this on all 3 platforms
AFAIK, there are no API incompatibilities.
Elias: recent mouse changes, with regards to mouse grabbed and delta - may cause breakage?
You guys are amazing! Thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you, thank you... well, you get the idea...
:D :D :D
Great news, especially for the mac support !
Chman
Ummm... is there supposed to be an OpenAL dll in the win32 versions package?
I'm getting this (using the Windows binary dist):
java.lang.UnsatisfiedLinkError: nalGenBuffers
at org.lwjgl.openal.AL10.nalGenBuffers(Native Method)
at org.lwjgl.openal.AL10.alGenBuffers(AL10.java:932)
at naroth.sound.OpenALSound.<init>(OpenALSound.java:66)
at naroth.util.SoundUtils.initSound(SoundUtils.java:15)
at naroth.util.SoundUtils.loadSounds(SoundUtils.java:25)
at naroth.Naroth.init(Naroth.java:121)
at naroth.start.StartFrame$Runner.run(StartFrame.java:208)
at java.lang.Thread.run(Thread.java:534)
BTW: Off topic, but i tried to post this using the link to the forum provided on the lwjgl-homepage. It doesn't work...
I forgot to add the oal dll - new file up:
lwjgl-win32-0.94-2.zip
Quote from: "EgonOlsen"
BTW: Off topic, but i tried to post this using the link to the forum provided on the lwjgl-homepage. It doesn't work...
Uhm, ... eh?
the link at the front page just points to this thread- can't see any reason for you not being able to post?
I think he's referring to the "Forum" link itself. It's pointing to forum.lwjgl.org, which isn't coming up.
Quote from: "Matzon"Quote from: "EgonOlsen"
BTW: Off topic, but i tried to post this using the link to the forum provided on the lwjgl-homepage. It doesn't work...
Uhm, ... eh?
the link at the front page just points to this thread- can't see any reason for you not being able to post?
No, i'm talking about the link on the left...that one to forum....
Ok, sound works now. How about util.timer? It seems to be broken as i'm getting negative times from it. It worked fine in 0.92 and 0.93, but now my game tries to adjust itself to -0.27272... :wink:
Edit: It works fine again if i'm replacing the lwjgl_util.jar of 0.94 with the one from 0.93
the forum stuff is temporary - the relevant dns server is down.
as for the timer stuff, I am not aware of any issues, however Cas did commit a timer change a week ago:
http://cvs.sourceforge.net/viewcvs.py/java-game-lib/LWJGL/src/java/org/lwjgl/util/Timer.java
It is allowed to create as many instances of Timer as i want, isn't it?
I compared the results that i'm getting from 0.93 and 0.94...they are both strange, but they only hurt in 0.94...let's see (i have 3 instances of Timer, all instanciated more or less at startup):
0.93
naroth.util.timer.LWJGLTimeProvider@13f7281:2.090642
naroth.util.timer.LWJGLTimeProvider@64883c:20855.654
naroth.util.timer.LWJGLTimeProvider@453807:1.1789659
This works becuase i care only for the delta, not for the times itself...but why does one Timer is counting 2xxxx...??
In 0.94, it looks like this:
naroth.util.timer.LWJGLTimeProvider@15bdc50:0.5311144
naroth.util.timer.LWJGLTimeProvider@18941f7:-0.19965774
naroth.util.timer.LWJGLTimeProvider@88e2dd:0.20388663
The behaviour is not what i expect, too. Anyway, this time it gives me negative values and that hurts me somewhere in my code.
An i using the Timer wrong? Can there only be one instance of it?
Edit: The code for LWJGLTimeProvider:
package naroth.util.timer;
import org.lwjgl.util.Timer;
import com.threed.jpct.*;
public class LWJGLTimeProvider implements TimeProvider {
private Timer timer=null;
public LWJGLTimeProvider() {
timer=new Timer();
Logger.log("Timer initialized: LWJGL hires timer", Logger.MESSAGE);
}
public long currentTimeMillis() {
timer.tick();
System.out.println(this+":"+timer.getTime());
return (long) (timer.getTime()*1000f);
}
}
I've modified LWJGLTimeProvider to work with one static instance of Timer, but to no avail. I wrote a test to see how it compared to my SunMiscTimeProvider. They are in sync for about 600ms. After that, the LWJGL-Timer fails, while the Sun one is still working as expected.
I've found something...this line:
currentTime = (int) Sys.getTime();
in Timer doesn't seem to be a good idea. My machine delivers something like 2083154160188 right after startup. Not a good idea to cast this into an int...
Quote from: "Matzon"
* Devil support (win32 initially)
This is so cool, thank you thank you thanky you !!! :)
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 :)
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.
Ah, could be.
Maybe I'll cast to a long and & it with 0x7FFFFFFFFFFFFFFF.
Cas :)
Quote from: "princec"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.
I'll get the fix up in a couple of hours.
Cas :)
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.
Yay! :D
Just that. Yay! :>
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!
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.
Quote from: "princec"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.