LWJGL 2.0 ALPHA

[Matzon]

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

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

[elias]

Slick Util javadocs are here: http://slick.cokeandcode.com/javadoc-util/

- elias

[Fool Running]

glu now uses buffers instead of arrays

Why was this done (out of curiosity)? Its written entirely in Java, isn't it?

[elias]

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

[kappa]

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

[elias]

* 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

[Fool Running]

You can use arrays by wrap()ing them

Oh, yeah. I forgot support for this was added.

[Qudus]

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

[darkprophet]

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

[elias]

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

[princec]

Can I suggest putting GLU into its own lwjgl_glu.jar, which would solve the problem to everyone's satisfaction?

Cas

[elias]

I would prefer lwjgl_glu.jar over lwjgl_util.jar, except some are also worried by the number of jars

- elias

[kevglass]

Let them worry.

Kev

[kappa]

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.

[Qudus]

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