This is the first stab at 2.0 - not much has changed yet
* glu moved to lwjgl_util
* no more processMessages at isCloseRequested, isVisible, isDirty and isActive
* glu now uses buffers instead of arrays
* fmod and devil removed
* dropped support for windows 9x
Get it here (http://sourceforge.net/project/showfiles.php?group_id=58488)
Since we have dropped fmod and devil, we strongly urge you to download the slick-util package, which has basic audio, texture and font support. Please get it here (http://slick.cokeandcode.com/downloads/util/)
Slick Util javadocs are here: http://slick.cokeandcode.com/javadoc-util/
- elias
Quoteglu now uses buffers instead of arrays
Why was this done (out of curiosity)? ??? Its written entirely in Java, isn't it?
To match the rest of the LWJGL library. You can use arrays by wrap()ing them, but you can't use buffers as arrays without copying. Besides, some GLU methods already used Buffers.
- elias
Quote from: Matzon on January 21, 2008, 23:05:37
* glu moved to lwjgl_util
just wondering why it was moved to the util package? it is a pretty commonly used and almost all 3d stuff is dependent on it.
Quote from: javalwjgl on January 23, 2008, 13:49:37
Quote from: Matzon on January 21, 2008, 23:05:37
* glu moved to lwjgl_util
just wondering why it was moved to the util package? it is a pretty commonly used and almost all 3d stuff is dependent on it.
Because it is not a necessary part of the core. GLU is strictly layered above lwjgl, so it belongs in lwjgl_util.jar, regardless of how often it is used.
- elias
QuoteYou can use arrays by wrap()ing them
Oh, yeah. I forgot support for this was added. ;D
Today I tried out the new 2.0 alpha release. And it is definitely a great release. Thanks a lot.
But I have two complains:
1. The glCallList() forces a checkGLErrors(), which makes it slightly slower. This shouldn't be forced. The "user" can always place an error check, if he needs it. Or maybe there should be a global flag to control the execution of additional error checks, which are unnecessary for a working production release of the using code.
2. As mentioned above the glu code has been moved to the util jar. I do need the glu package, but I definitely don't need all the other stuff from the lwjgl_util.jar. OK, I could just ignore the other classes, but since they are in the classpath, they appear in Eclipse'es auto-completion list, which is a little bit annoying. Would be cool, if glu was moved back to the code jar or placed in some additional jar. My local solution is to copy the glu package into the lwjgl.jar.
Marvin
GLU stuff are just utility methods, hence why they should be in the util jar. Your probably not using half of the extensions available in lwjgl.jar, does that mean we should remove those too?
The most likely calls your making is either GLU.gluOrtho2D, GLU.gluPerspective or GLU.gluLookAt. In any case, all they do is some processing and then call a proper GL call, which you can do yourself. Look at the GLU source to find out how to do those GL calls.
I for one hand do not use GLU and agree that it should be in the util.jar.
DP :)
Quote from: Qudus on January 27, 2008, 16:39:07
1. The glCallList() forces a checkGLErrors(), which makes it slightly slower. This shouldn't be forced. The "user" can always place an error check, if he needs it. Or maybe there should be a global flag to control the execution of additional error checks, which are unnecessary for a working production release of the using code.
LWJGL 2.0a was accidentially built with debug calls, they should be gone in 2.0 alpha 2.
- elias
Can I suggest putting GLU into its own lwjgl_glu.jar, which would solve the problem to everyone's satisfaction? :)
Cas :)
I would prefer lwjgl_glu.jar over lwjgl_util.jar, except some are also worried by the number of jars :)
- elias
Let them worry. :)
Kev
Quote from: elias on January 28, 2008, 12:08:04
I would prefer lwjgl_glu.jar over lwjgl_util.jar, except some are also worried by the number of jars :)
- elias
agreed the number of jars was the reason i was unhappy with this change, as before you only had to worry about one external jar. Besides if you are worried about size you can always use something like proguard to remove the unnecessary stuff from a jar.
Quote from: darkprophet on January 27, 2008, 22:50:02
GLU stuff are just utility methods, hence why they should be in the util jar. Your probably not using half of the extensions available in lwjgl.jar, does that mean we should remove those too?
The most likely calls your making is either GLU.gluOrtho2D, GLU.gluPerspective or GLU.gluLookAt. In any case, all they do is some processing and then call a proper GL call, which you can do yourself. Look at the GLU source to find out how to do those GL calls.
No, it's not the matrix generation functions, that I am using from GLU, but the sphere rendering methods, which I am using to draw bounds for debugging. Well, of course I can create my own sphere render code, which I will probably do. So it's fine for me.
Marvin
Quote from: javalwjgl on January 28, 2008, 14:14:57
Quote from: elias on January 28, 2008, 12:08:04
I would prefer lwjgl_glu.jar over lwjgl_util.jar, except some are also worried by the number of jars :)
- elias
agreed the number of jars was the reason i was unhappy with this change, as before you only had to worry about one external jar. Besides if you are worried about size you can always use something like proguard to remove the unnecessary stuff from a jar.
If you're worried about the number of jars you can always repack 'em.
Another vote for lwjgl_glu.jar ;)
personally im not fussed on the number of jar's.
For the sake of new LWJGL users I think less is better because a few people use lwjgl to learn about opengl. I think alot of people had trouble getting the stuff in the util packages to work because they didnt know about extra jar files. Once people are confident with lwjgl they can chop and change it around the way they like.
like i said, Im happy with any setup you guys decide. Keep up the great work!
However, I am concerned about the number of itty bitty downloads I'm doing to get a release - I'd rather all the stuff was put into a single released zip file instead of the 5 or 6 separate downloads we have at the moment.
Cas :)
I would say chop things up as much as possible, using proguard or having to manually repackage things is annoying. Modern IDEs like Eclipse make it a breeze to add JAR-files to the classpath. Please, please do chop everything up as much as possible to allow easy picking and choosing.
N00bs (gotta love that word :P ) can just select the whole bunch, right-click and choose "Build Path"->"Add to Buildpath" and voila they are up and running with no missing classes.
Would be nice to actually port OpenAL-Soft into pure Java and have a number of small native backends to actually output the sound...
Cas :)
Quote from: princec on March 07, 2008, 18:06:18
Would be nice to actually port OpenAL-Soft into pure Java and have a number of small native backends to actually output the sound...
Cas :)
hehe, wouldn't it be quicker to just start from scratch ? :)
Quote from: princec on March 07, 2008, 18:06:18
Would be nice to actually port OpenAL-Soft into pure Java and have a number of small native backends to actually output the sound...
Cas :)
Agreed. Seems like a good way to get stable sound support.