LWJGL 1.0 beta2 Released

[Matzon]

grab it here:
http://sourceforge.net/project/showfiles.php?group_id=58488

As always, consider donating if you like LWJGL

Notes:
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

[numberR]

oh wow.
applet thing is impressive.

[elias]

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

[Fool Running]

Yeah! New release

[Sormuras]

Cheer!

[miu]

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..."

[Bryan]

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?

[numberR]

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!

[numberR]

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.

[numberR]

... 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.

[elias]

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

[numberR]

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...?

[numberR]

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.

[Bryan]

Thumbs up on that one  

[numberR]

sweet.
thanks for reporting.