Let .9 out

OpenGL Development
#1

so that we can port Xith3D to it ;D

#2

hehe
we’re scheduling 0.9 for easter, but once we’ve gotten the initial extension refactor done - you might as well grab a cvs build…

#3

come to think of it… I think the initial refactor IS done - we just have some small issues we need to deal with before releasing (aka bugs ;))

#4

If you like I’ll do a CVS build, call it 0.89 and post it up on puppygames. The API will not be changing significantly from this point on.

Cas :slight_smile:

#5

I have a quick fix I’d like to see added, glDepthMask() takes a boolean as a parameter, yet GL_TRUE is defined as an int, when porting code on the web between different languages it would be nice not to have to fix these little things by hand.

I also noticed that LWJGL v0.8 has moved slightly away from the standard opengl method naming convention. I realise that the parameters to these functions can’t be the same since we use buffers for many of these calls, but it would be nice to still keep the original method name.

Again I’m speaking from a porting of code point of view, it would really help clueless newbies like myself from having to figure out opengl and how to convert it to work with LWJGL methods.

I’m happy to say that I’m now using v0.8 with static imports under Java v1.5b and using sample code off the web is almost a cut and paste straight to a compile.

Keep up the good work!

Thanks.

Andy.

#6

We ought to fix that boolean… it should be an int, yes. But the few method names we’ve changed is deliberate, as usage of the new javaified methods is significantly different from the C API, and it needs to be carefully thought about when porting.

Only the i/f/v postfixes have been removed anyway, which are now directly inferred from the fact that you’re using a Buffer (therefore v is implied) and the type of the Buffer determines i or f. The other methods stay as they are to avoid too much brain adjustment.

Cas :slight_smile:

#7

I also have an idea for a common code simplification, kind of related to the code I’ve been writing for frustum culling.

I’m thinking that many people may have code to do frustum culling in their applications, and will therefore have code somewhere that looks like this :-


projBuf.rewind();
modlBuf.rewind();

// nice static imports means no more GL. everywhere! 
glGetFloat(GL_PROJECTION_MATRIX, projBuf);
glGetFloat(GL_MODELVIEW_MATRIX, modlBuf);
 
projBuf.rewind();
modlBuf.rewind();
 
projBuf.get(proj);
modlBuf.get(modl);

what I’d like to see, and I know this has been touched on before, is code that looks like this instead :-


glGetFloat(GL_PROJECTION_MATRIX, proj);
glGetFloat(GL_MODELVIEW_MATRIX, modl);

Now creating a new FloatBuffer inside this call would be expensive (in terms of speed/object creation), but could LWJGL have a private FloatBuffer (initialised internally at application startup) of a big enough size (256?) to accommodate the largest of the different GL_PROJECTION_MATRIX enum values, and automatically wrap up the supplied float[] and do the necessary rewind() and get() methods.

This could then also lead to a reverting of the decision to drop the v from methods like this that should be called glGetFloatV().

As you’ll now be realising I like to keep my OpenGL java code as much like the C code that I’ve been trying to learn from on the web, and from books.

Thanks,

Andy.