Hello Guest

LWJGL 1.0 beta2 Released

  • 28 Replies

Offline Matzon

  • *****
  • 2242
LWJGL 1.0 beta2 Released
« on: July 12, 2006, 20:58:44 »
grab it here:

As always, consider donating if you like LWJGL

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.

* 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

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

LWJGL 1.0 beta2 Released
« Reply #1 on: July 12, 2006, 23:43:17 »
oh wow.
applet thing is impressive.


Offline elias

  • *****
  • 899
    • http://oddlabs.com
LWJGL 1.0 beta2 Released
« Reply #2 on: July 13, 2006, 08:40:08 »
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

« Reply #3 on: July 13, 2006, 13:42:28 »
Yeah! New release :D
Programmers will, one day, rule the world... and the world won't notice until its too late.Just testing the marquee option ;D

LWJGL 1.0 beta2 Released
« Reply #4 on: July 14, 2006, 09:04:04 »


Offline miu

  • *
  • 36
Way to go!
« Reply #5 on: July 14, 2006, 17:01:49 »
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..."

LWJGL 1.0 beta2 Released
« Reply #6 on: July 15, 2006, 12:58:02 »
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?

LWJGL 1.0 beta2 Released
« Reply #7 on: July 15, 2006, 14:31:38 »

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!

LWJGL 1.0 beta2 Released
« Reply #8 on: July 16, 2006, 21:15:31 »
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.

LWJGL 1.0 beta2 Released
« Reply #9 on: July 17, 2006, 00:12:37 »
... and here is script to build DevIL.


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.


Offline elias

  • *****
  • 899
    • http://oddlabs.com
LWJGL 1.0 beta2 Released
« Reply #10 on: July 17, 2006, 12:59:34 »
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

LWJGL 1.0 beta2 Released
« Reply #11 on: July 18, 2006, 05:09:53 »
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:
Code: [Select]

#ifdef _WIN32
 #include "extilu.h"
 static HMODULE devILUhandle;
 #include <dlfcn.h>
 #include "extilu.h"
 #include <libgen.h> <-- adding this
 static void* devILUhandle;


#ifdef _WIN32
devILUThandle = LoadLibrary(path_str);
char* directoryName = dirname(path_str);
char* fileName = basename(path_str);
char* currentDirectory = getwd(NULL);
if(directoryName != NULL)

devILUThandle = dlopen(fileName, RTLD_LAZY);
if(devILUThandle == NULL) {
printfDebug("dlopen failure: %s", dlerror());


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

LWJGL 1.0 beta2 Released
« Reply #12 on: July 18, 2006, 07:13:11 »
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.

LWJGL 1.0 beta2 Released
« Reply #13 on: July 25, 2006, 14:05:33 »
Thumbs up on that one   :D

LWJGL 1.0 beta2 Released
« Reply #14 on: July 26, 2006, 01:01:44 »
thanks for reporting.