grab it here:
http://sourceforge.net/project/showfiles.php?group_id=58488
As always, consider donating (http://lwjgl.org/donations.php) if you like LWJGL
QuoteNotes:
Note:
applet test libraries are signed by lwjgl and includes fmod binaries that are used for demonstration purposes. You should only use the signed fmod lwjgl libs if you comply with the fmod license.
Applets are known to work in Firefox and Internet Explorer. Opera crashes for unknown reasons.
Noteworthy:
* Applet support
* Universal binary for Devil
* fmod3 internally references linked music/sound so they're not garbage collected prematurely.
* Misc. bug fixes to mouse input
Minor:
* Misc 64bit changes
* Misc internal changes to minimize the amount of native code
* Fixed memory leak issues related to setIcon
* Version check on loading of fmod/devil
* Updates to math packages
* Support for WGL_ATI_pixel_format_float
For info on using applets, check the wiki:
http://lwjgl.org/wiki/doku.php/lwjgl/tutorials/index#other
oh wow.
applet thing is impressive.
Just to clear out any confusion: floating point pixel formats are supported on all three platforms (if the required extensions are available), not only on windows. Additionally, beta2 includes the fixes for the two AWTGLCanvas problems in beta1 (flickering on mac os x and the problem with modal dialogs invoked from paintGL()).
- elias
Yeah! New release :D
Cheer!
Thanks a lot for your continuing effort!
I haven't used DevIL yet, now I can test it under Mac Intel!
"Getting so much better all the time..."
Does DevIL being a Universal binary cover ILU and ILUT? I'm using an Intel iMac, and ILU.create() throws an exception, with the string "Could not load ilu library". IL.create() works fine, as does all the other LWJGL stuff, and I've got libILU.dylib in the same folder as all the other native stuff. The same code works fine Windows.
If this is a bug, and not a know issue or just me being dim, is there any other info I can give you to help?
hi,
i'm aware of that issue and haven't figured out what is causing the issue yet :(
first, i need to figure out if this is due to DevIL itself or DevIL with LWJGL.
since DevIL-1.6RC1 does not compile on Intel Mac OS X without some modifications,
i was waiting for RC2 to come out, but i'll try it soon again to see if latest code also has this issue or not.
i'm also writing a script so people can easily compile DevIL with all other external libraries that would be linked statically to it.
sorry for not being everything ready, but getting close!
ok, i figured out the cause of this issue.
in order for dylibs dependencies, such as libILU.dylib needs libIL.dylib to be loaded and so on, to be solved when loading dylibs with dlopen, a path passed to dlopen has to MATCH with what you see with `otool -L` command.
for example, let's say LWJGL passes "lib/libIL.dylib" to dlopen to load libIL.dylib. then, when LWJGL tries to load libLU.dylib, dlopen checks if libIL.dylib is already loaded by looking at entries from `otool -L libILU.dylib`.
let's say `otool -L libILU.dylib` shows just "libIL.dylib" as dependency for libIL.dylib. then, calling dlopen to load libILU.dylib fails because libIL.dylib was loaded with the path "lib/libIL.dylib" even `otool -L libILU.dylib` expects libIL.dylib to be located at "libIL.dylib".
i was using install_name_tool and changing values just for my environment, and i got DevIL working on intel/ppc Mac OS X.
so, DevIL will be functional if we solve this issue.
at the moment, i have no idea how we should fix this issue,
but yea, this was the issue.
... and here is script to build DevIL.
http://janedoe.homeunix.org:9449/~atsuya/KusariyukuSekai/DevIL/Data/DevILBuilder.sh
you can specify where libpng, libjpeg and libtiff are located and done!
what you should do, is to compile libpng, libjpeg and libtiff in directory other than /usr or /usr/local or anything, and just compile then into .a but .dylib (you can specify "--disable-shared --enable-static" for configure"). then, just specify the path for those libraries to the script.
note that DevIL-1.6-RC1 does not compile on Mac OS X PPC since there is bug in DevIL. you can modify Makefile to make it work. take a look at DevIL's forum.
ones you get DevIL compiled on both of Intel/PPC, then simply use lipo command to create universal binary out of them.
Would it help if we distributed devil as a complete framework with all libraries included instead of three distinct .dylibs? The OpenGL loading code already uses the framework-oriented approach (see src/native/macosx/context.m::loadFramework) to load the OpenGL library.
- elias
yes, it would help.
but the reason why i was working on this dylib thing was to make it easy to deploy DevIL...
and i figured one way to fix this issue.
the problem with dlopen was that, if you pass path like "lib/libIL.dylib", then dlopen takes that whole string as a filename. so, if we can change directory to "lib" in this case, and just load "libIL.dylib", then it seems to work.
i modified extil*_Open functions in src/native/common/devil/extil*.c in following way:
#ifdef _WIN32
#include "extilu.h"
static HMODULE devILUhandle;
#else
#include <dlfcn.h>
#include "extilu.h"
#include <libgen.h> <-- adding this
static void* devILUhandle;
#endif
...
#ifdef _WIN32
devILUThandle = LoadLibrary(path_str);
#else
char* directoryName = dirname(path_str);
char* fileName = basename(path_str);
char* currentDirectory = getwd(NULL);
if(directoryName != NULL)
{
chdir(directoryName);
}
devILUThandle = dlopen(fileName, RTLD_LAZY);
if(devILUThandle == NULL) {
printfDebug("dlopen failure: %s", dlerror());
}
chdir(currentDirectory);
free(currentDirectory);
#endif
and if we change entries shown by `otool -L` for libIL*.dylib to just "libIL.dylib" and "libILU.dylib", then now it should all work.
people can put dylibs in any path and just can be referenced by java.path.library.
how do you think of this approach?
i haven't tries this on Linux but i assume it would work on Linux as well...?
http://janedoe.homeunix.org:9449/~atsuya/KusariyukuSekai/DevIL/Data/LWJGL-DevIL-UniversalBinary-20060717.tar.bz2
i incorporated the approach and i think this one works!
if you could not get DevIL working with previous one,
please test this one and let me know how it goes.
Thumbs up on that one :D
sweet.
thanks for reporting.
I'll add these binries for beta 3.
Thanks for your hard work numberR!!
thanks.
i modified the code as described before and compiled on Linux (FC5) to see if that would work on Linux as well as Mac OS X.
it seems that it won't work on Linux if you make that change.
it seems to work only on Mac OS X.
(dlopen on Linux does not look for library in current directory?)
so, if you are planning to incorporate that change,
you may want to do the modification just for Mac OS X, maybe using #ifdef for Mac OS X.
calling Display.destroy() crashes my lwjgl ... this may be due to the fact that i running the modularized X.org 7.0-r1 (on gentoo)
java crashes with this message:
Quote#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
# SIGSEGV (0xb) at pc=0x99be16de, pid=16438, tid=2582830000
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_07-b03 mixed mode)
# Problematic frame:
# C [libX11.so.6+0x536de] XDestroyIC+0x1e
#
# An error report file with more information is saved as hs_err_pid16519.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
i'll attach the hs_err_pid ... aah ... i can't attach anything ... it can be viewed here: http://www.fhaust.de/downloads/hs_err_pid16519.log
any ideas anyone?
Greets ... Golly
nasty - this is something for elias 8) - or someone with linux experience!
Can you post a test program that crashes? Or does it crash with one of the LWJGL tests?
- elias
org.lwjgl.test.opengl.Gears -> crashes on shutdown
org.lwjgl.test.opengl.VBOTest -> crashes on shutdown
org.lwjgl.test.opengl.FullScreenWindowedTest -> crashes on startup :( (guess this is not related)
-> yes ... lwjgl tests are running but crash on shutdown (which btw removes the 'key repeater' for the rest of the system)
Can you post the crash trace for the FullScreenWindowedTest? I think I fixed the crash on shutdown.
- elias
Quoteflorian@faust ~/workspace/libs/lwjgl-1.0beta2/jar $ java -cp lwjgl.jar:lwjgl_test.jar:lwjgl_util.jar -Djava.library.path=../native/linux/ org.lwjgl.test.opengl.FullScreenWindowedTest
Change between fullscreen and windowed mode, by pressing F and W respectively
Move quad using arrowkeys, and change rotation using +/-
java.lang.NullPointerException
at org.lwjgl.test.opengl.FullScreenWindowedTest.glInit(FullScreenWindowedTest.java:257)
at org.lwjgl.test.opengl.FullScreenWindowedTest.initialize(FullScreenWindowedTest.java:86)
at org.lwjgl.test.opengl.FullScreenWindowedTest.execute(FullScreenWindowedTest.java:73)
at org.lwjgl.test.opengl.FullScreenWindowedTest.main(FullScreenWindowedTest.java:273)
Exception in thread "main" java.lang.NullPointerException
at org.lwjgl.test.opengl.FullScreenWindowedTest.processKeyboard(FullScreenWindowedTest.java:199)
at org.lwjgl.test.opengl.FullScreenWindowedTest.mainLoop(FullScreenWindowedTest.java:100)
at org.lwjgl.test.opengl.FullScreenWindowedTest.execute(FullScreenWindowedTest.java:74)
at org.lwjgl.test.opengl.FullScreenWindowedTest.main(FullScreenWindowedTest.java:273)
here it is :)
just another thing ...
when i try to compile lwjgl myself i get an an error saying that cc can't find jawt.h at the compile_native_linux target
Quote[apply] /home/florian/workspace/lwjgl/src/native/linux/org_lwjgl_opengl_Display.c:50:18: jawt.h: No such file or directory
in platform_build/linux_ant/build.xml it says
Quote<arg value="-I${java.home}/include"/>
and this
Quotelocate jawt.h
/opt/sun-jdk-1.4.2.12/include/jawt.h
/opt/sun-jdk-1.5.0.07/include/jawt.h
indicates that jawt.h is where cc is searching it ... replacing ${java.home} with the correct path doesn't help either ...
any ideas why it can't be found?
Any ideas on a beta3 release timescale?
Kev
it was going to be this weekend, then I hosed my windows installation, so I thought I'd change priorities a bit...
some time next week should be fine tho
Any chance you'll do a wrapper for the jInput rumbler? ;)
I'd love to test my force feedback joystick, although I have a feeling the FF supoort in jInput isn't quite the same as the one supplied by DirectX, but you never know... ;)
Hey,
how about adding a getButtonIndex for Controller,
this type of function exists for keyboards and mice, but not Controller, Controller only has getButtonName.
Also, getEventNanoseconds and a getEventButtonState for Controllers would be nice as well.
beta 3 is tagged and almost ready to go - the usual round of linux dissing me is preventing me with the release...