LWJGL 0.7 (pre) released!

[princec]

Cool, I hope this makes the library a bit smaller and simpler.

Cas

[spasi]

Another problem has occured. 0.6 had glMultiDrawArrays and worked fine, but 0.7 has both glMultiDrawArrays and glMultiDrawArraysEXT and only the EXT version works. Actually there's no native implementation (or even declaration) of the standard glMultiDrawArrays version. And I was wondering why glMultiDrawElements does not exist (actually commented out). Is there a reason for this? That "GLvoid **indices" maybe?

Any idea about when final 0.7 will be ready?

[elias]

The glMultiDrawElements is commented out because of the GLvoid ** issue which I can't readily convert to Buffers.

But I'm not following you regarding glMultiDrawArrays? There's a native implementation in common/org_lwjgl_opengl_CoreGL.cpp, right?

- elias

[spasi]

You're right. It's in CoreGL and I was looking in GL And that's really strange because I'm getting a "java.lang.UnsatisfiedLinkError:glMultiDrawArrays" whenever I call glMultiDrawArrays. glMultiDrawArraysEXT works fine.

[elias]

oh, then it's fixed in the second conversion round I did yesterday. Wait for 0.7 final.

- elias

[tvaananen]

Hi,

I have to agree with Fuseboy. I am not a game programmer and I do not know GL and so on, but I do know about programming.

I downloaded the 0.7 release just to poke around to see if I can create something with it. My excitement quickly turned into disbelief when I saw how the stuff was ported to Java.

I understand your point about it being hard to make C-interface look like OO Java. That's fine, if your goal was just to make the bridge to the Java world using this interface, and nothing else.

If your aim is to directly use this interface for game programming in Java, then I completely disagree with the current approach.  It gives little or no advantage from the design/programming point of view and brings the same problems from the C world that you tried to avoid with Java!

It would be great if there was some layer design to this. Your current design would be bottom layer just to interface with the system level services via GL etc. It would rarely be used directly by the game programmer.  On top of this interface, there would be an object abstraction layer that would model everything as objects.

Only after you do this, can you really start to see the benefits of Java. It's fine that Java takes care of so many things for you, but ultimately, your benefits will melt away if you do not model things in objects. The idea with objects is to model things to concrete classes so that you can understand your program better. An apple would be an apple, instead of pulp + seeds + peel + juice. Do you see an apple in a pile of pulp, seeds, peel and juice? That's the difference.

Anyway, it's good to see that Java gaming is becoming a reality.

[cfmdobbie]

Yep, a full object layer can be very, very useful - but that's out of the scope of LWJGL.  The community is encouraged to produce whatever layers on top they require, however.

Many C/C++ development houses these days touch OpenGL/Direct3D very little, and instead delegate all the "graphics stuff" to a piece of middleware, a scenegraph etc.  Anyone who wants to write a scenegraph on top of LWJGL may do so, and that's basically the stage of development LWJGL is at.

I personally see the next stage as a very primitive object layer to encapsulate the OpenGL-defined objects - Textures etc - and the various utility code that everyone has to write.  Then, scenegraphs, tile renderers, model loaders etc.  I'm sure in time all these things will exist.