LWJGL 0.95 Released
Time for yet another release - steadily approaching 1.0!
Changes:
* EAX removed (was win32 specific)
* Controller removed (only worked on win32, will return later in some other form)
* LOTS of bug fixes
* Move and rename of Pbuffer.getCapabilities() and Cursor.getCapabilities()
* Support for EXT_framebuffer_object (missing driver support)
* DevIL support now includes ILU/T (still in progress)
Get it here: https://sourceforge.net/project/showfiles.php?group_id=58488&package_id=54362&release_id=299852
I'll update JNLP tomorrow - can't be bothered with it now :)
I tried to run my game (which was working under 0.94) but before the display was created the game quitted. I looked at the exception-output, but there was no exception. What's wrong?
WiESi
uhm... no idea... can you share a copy so that I may debug it ?
Ah, now I found the problem: when I call IL.create() the program quits for some reason.
WiESi
probably because you don't have the devil dll's included - but it should give an error ?
hello guys.
i was trying 0.95 on Linux and i got following error when i tried to run my program that used to be running fine with 0.94:
Exception in thread "main" java.lang.UnsatisfiedLinkError: /home/atsuya/mydoc/dev/gltalk/java/lwjgl/lib/liblwjgl.so: libmawt.so: cannot open shared object file: No such file or directory
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1676)
at java.lang.Runtime.loadLibrary0(Runtime.java:822)
at java.lang.System.loadLibrary(System.java:992)
at org.lwjgl.Sys.<clinit>(Sys.java:69)
at org.lwjgl.opengl.Display.<clinit>(Display.java:92)
at MD3Loader.initializeDisplay(MD3Loader.java:63)
at MD3Loader.<init>(MD3Loader.java:33)
at MD3Loader.main(MD3Loader.java:276)
that contains some of my stuff, but it seems like liblwjgl.so was compiled against libmawt.so. is this what expected to be happened or maybe a compiling issue? both of copying libmawt.so to my java.library.path and adding /usr/java/jdk1.5.0/jre/lib/i386/motif21 to my java.library.path did not work.
Quote from: "Matzon"probably because you don't have the devil dll's included - but it should give an error ?
Thx, that was the problem.
WiESi
Strange. I'm linking libjawt.so (notice the 'j') to liblwjgl.so to be able to access AWT features (for synchronizing AWT with LWJGL which is needed on X11 implementations). I'm not sure why it needs libmawt.so (with an 'm') though. Here's the output from ldd:
elias@ip173:~/cvs/lwjgl/src/native/linux> ldd liblwjgl.so
linux-gate.so.1 => (0xffffe000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4003e000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4013a000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x4015f000)
libjawt.so => not found
libc.so.6 => /lib/tls/libc.so.6 (0x40171000)
libdl.so.2 => /lib/libdl.so.2 (0x40287000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
- elias
One thing is sure though, it won't help to muck around with java.library.path since it's a native linking problem. Try adding libmawt.so to your LD_LIBRARY_PATH instead.
- elias
There's something about it here:
http://forum.java.sun.com/thread.jspa?forumID=32&threadID=326048
but that seems to apply only to solaris.
- elias
thanks for the reply.
i got it to work, but it's still strange.
it seems like libjawt is linked against libmawt.so. here is my ldd:
[atsuya@localhost i386]$ ldd libjawt.so
libawt.so => not found
libmawt.so => not found
libjava.so => not found
libjvm.so => not found
libc.so.6 => /lib/tls/libc.so.6 (0x00180000)
/lib/ld-linux.so.2 (0x0085c000)
the problem is libjawt.so cannot find libmawt.so. i figured out that there are, at least, two of libmawt.so, which java seems to choose which one to use depending on system. on solaris it uses one in motif21 directory and on linux it uses one in xawt directory.
so i created symbolic link to /usr/java/jdk1.5.0/jre/lib/i386/xawt/libmawt.so in /usr/java/jdk1.5.0/jre/lib/i386. i thought this should be enough, but when i run my program, it said:
Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load library: /home/atsuya/mydoc/dev/gltalk/java/lwjgl/lib/xawt/libmawt.so
/home/atsuya/mydoc/dev/gltalk/java/lwjgl/lib is where all my lwjgl stuff is sitting, and it seems like it looks for xawt/libmawt.so from my lwjgl directory. so i copied it there and it worked. but it's strange. linking other awt library might help?
Quote from: "WiESi"Ah, now I found the problem: when I call IL.create() the program quits for some reason.
WiESi
I still have this problem. I got the error message that ILU.dll could not be found. But I have it in my path because it works under 0.94. All I do is provide -Djava.library.path=path_to_lwjgl;path_to_devil and simply switch the path of lwjgl. Result: runs under .94, runs not under .95
due to interdependencies you need the ilu.dll and ilut.dll too
I have all devil related dlls in my path: DevIL.dll, ILU.dll and ILUT.dll, they are all located in one folder that I reference via -Djava.library,path...
Quote from: "baegsi"I have all devil related dlls in my path: DevIL.dll, ILU.dll and ILUT.dll, they are all located in one folder that I reference via -Djava.library,path...
Sorry. DevIL doesn't check the java.library.path yet. I will fix that tonight, but for now you have to put the dlls in your path or in the same spot you are executing from.
Thanks, that's great. No need to rush though, I can still use .94 until then or do what you suggested. It's just good to know that the error is not on my side
Quote from: "CaptainJester"Quote from: "baegsi"I have all devil related dlls in my path: DevIL.dll, ILU.dll and ILUT.dll, they are all located in one folder that I reference via -Djava.library,path...
Sorry. DevIL doesn't check the java.library.path yet. I will fix that tonight, but for now you have to put the dlls in your path or in the same spot you are executing from.
I think I am wrong. I think it is supposed to automatically check the java.library.path if it exists. Can someone confirm this?
Thanks.
I have the same problem numberR mentioned above. I can get the failed dependecy to go away, but when I try to use javax.imageio.ImageIO.read() to read in PNG files. It blows up with a newer depenedency failure for the same libmawt.so???? anyone got any ideas?
I am running FC3 on AthlonXP with jdk1.5.0_01
[edit] I finally got it to work by copying the so's into /opt/jdk1.5.0_01/jre/lib/i385 and taking out the -Djava.libra.... stuff. perhaps the jre doesn't know which libmawt to use after some new change to lwjgl? (motif, headless and xawt exist)
The bug is described here:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4976297
What is puzzling is that it is marked as "fixed" in beta 2, but the problem is obvious still there.
- elias
I have now re-posted the bug. We'll see what happens then.
- elias
I noticed that this isn't a simple drag-and-drop replacement for v0.9.4. The method Keyboard.enableBuffer() seems to have been removed.
Caused by: java.lang.NoSuchMethodError: org.lwjgl.input.Keyboard.enableBuffer()V
Was this mentioned in the changelog or release notes?
Cheers,
Andy.
it's all in the changelog - however, not in the relase notes :)
Would it be possible in future to mark these methods as deprecated, and only remove them in v1.0 that way I don't have to go through my entire code suit with each release of LWJGL and make changes. This would allow me to choose when to remove the redundant code and if the Javadoc said it wouldn't be present at v1.0 I'd have an indication of when I had to remove it by.
Just ripping code out of the public API is very annoying to the developers, especially since the enableBuffering() method is likely to have been used by everyone!
Thanks,
Andy.
Great work! :)
Just out of curiosity, how can my program read the current version number of lwjgl it is running?
This libmawt problem looks familiar. It showed up first in one of the early betas (beta1?) of JDK1.5.
The funny thing is, that is really fixed in beta2 and 1.5.0. At least I have not the problem some people are describing with the *first* release of JDK1.5.0
Quote from: "blue_tomato"Just out of curiosity, how can my program read the current version number of lwjgl it is running?
It can't. Unless you uses Introspection and grab the
private final static SysImplementation implementation;and call getNativeLibraryVersion on it. However you're on your own when you do that kind of stuff - and it will probably break.
Do we need a public method for getting the version ?
Quote
The funny thing is, that is really fixed in beta2 and 1.5.0. At least I have not the problem some people are describing with the *first* release of JDK1.5.0
i just downloaded the latest version of JDK 1.5.0, but no luck. maybe linux distribution dependent issue because i also use Fedora Core 3 as well as Zero. What do you use, theBohemian?
Wrong date!
LWJGL 0.95 released! Tuesday, January 25th, 2004 <------
0.95 released. Lots of fixes. Thanks everybody. Please check this thread for more info regarding the release
meh, copy paste bug, will fix tonight :)
As documented in the release changelog here:
http://lwjgl.org/changelog.php
Keyboard.enableBuffer() was removed from the public API.
Questions:
Why was it removed? Will it resurface elsewhere or is gone for good?
Is there a replacement in 0.95? It's incredibly handy.
Regards,
Owen Butler
There's no need to enable it any more - because it's always enabled!
Cas :)
Quote from: "OwenButler"As documented in the release changelog here:
http://lwjgl.org/changelog.php
Keyboard.enableBuffer() was removed from the public API.
Questions:
Why was it removed? Will it resurface elsewhere or is gone for good?
Is there a replacement in 0.95? It's incredibly handy.
Regards,
Owen Butler
I'm guessing you misunderstand the "removal". It is only removed from the public API, and is now simply private and automatically called from Keyboard.create() (which is called automatically from Display.create()). The buffered functionality is still there. but the explicit enable is just gone.
- elias
Well that is great, thanks!
Quote from: "Zero"I have the same problem numberR mentioned above. I can get the failed dependecy to go away, but when I try to use javax.imageio.ImageIO.read() to read in PNG files. It blows up with a newer depenedency failure for the same libmawt.so???? anyone got any ideas?
I am running FC3 on AthlonXP with jdk1.5.0_01
[edit] I finally got it to work by copying the so's into /opt/jdk1.5.0_01/jre/lib/i385 and taking out the -Djava.libra.... stuff. perhaps the jre doesn't know which libmawt to use after some new change to lwjgl? (motif, headless and xawt exist)
I think I found a fix to the problem. Calling Toolkit.getDefaultToolkit() before loading the lwjgl native lib seems to work. The fix is added to CVS, but you can easily add the line to your applications in the meantime.
- elias
Quote from: "elias"Quote from: "Zero"I have the same problem numberR mentioned above. I can get the failed dependecy to go away, but when I try to use javax.imageio.ImageIO.read() to read in PNG files. It blows up with a newer depenedency failure for the same libmawt.so???? anyone got any ideas?
I am running FC3 on AthlonXP with jdk1.5.0_01
[edit] I finally got it to work by copying the so's into /opt/jdk1.5.0_01/jre/lib/i385 and taking out the -Djava.libra.... stuff. perhaps the jre doesn't know which libmawt to use after some new change to lwjgl? (motif, headless and xawt exist)
I think I found a fix to the problem. Calling Toolkit.getDefaultToolkit() before loading the lwjgl native lib seems to work. The fix is added to CVS, but you can easily add the line to your applications in the meantime.
- elias
it worked for me as well by calling Toolkit.getDefaultToolkit() before loading the lwjgl native lib. is Toolkit.getDefaultToolkit() necessary for all AWT application?
Quote from: "numberR"
it worked for me as well by calling Toolkit.getDefaultToolkit() before loading the lwjgl native lib. is Toolkit.getDefaultToolkit() necessary for all AWT application?
No. Any AWT call (creating a Canvas would do the trick too) will initialize AWT the same way. Toolkit.getDefaultToolkit() is just one way to do it.
- elias
i see. anyway, thanks for finding solution for the problem and the fix to CVS.