Hi! I have examined your binding and I have some suggestions on how to make it better. There are some things that I consider very weird.

1. There are no functions like

1

glVertex3fv(float[])

or like

1

glMaterialfv(...)

. I would rather prefer to use arrays than a "float, float, float" chain or Buffers in this case. 2. Why do use subclasses of Buffer rather than the Buffer itself? It is very strange.3. Why don't you make a private constructor in GL11-15 classes and all other utility classes. They shouldn't have a public constructor and shouldn't be instatiated as all methods and fields are static!4. Why do use only the ByteBuffer in gluBuild2DMipmaps function?5. Why did you change GL names? I find it very inconvenient

Hi! I have examined your binding and I have some suggestions on how to make it better. There are some things that I consider very weird.

Hi, and thanks for your comments. LWJGL has evolved a long way since its first inception. The way it is today is basically because it *feels* right, for the majority of the developers. That said, there will be some that want it to behave differently - we can't please everybody

Quote

1. There are no functions like

1

glVertex3fv(float[])

or like

1

glMaterialfv(...)

. I would rather prefer to use arrays than a "float, float, float" chain or Buffers in this case.

Yes, it is more convenient - unfortunately this is exactly how you kill performance. When OpenGL renders, it wants its data fast. By using arrays you are forced to move data from within the VM which is considerably slower than using a direct ByteBuffer or variants thereof. See 5 too.

Quote

2. Why do use subclasses of Buffer rather than the Buffer itself? It is very strange.

We use subclasses of bytebuffers so that we know the datatype, and thus the offset into the buffer for elements.

Quote

3. Why don't you make a private constructor in GL11-15 classes and all other utility classes. They shouldn't have a public constructor and shouldn't be instatiated as all methods and fields are static!

Sure we could do that... but I actually don't see any user *benefit* from doing it... you can't use a GL11 instance for anything and it's a final class anyway - it would simply be for the sake of being more OOish

Quote

4. Why do use only the ByteBuffer in gluBuild2DMipmaps function?

See 1. Why not? - an image is just bytes - why wrap it in something else?

Quote

5. Why did you change GL names? I find it very inconvenient

The names that were changed was because they didn't make sense in Java (they were removed entirely) or because the actual purpose of the method [gl*f, i, b] was implied by the type of Buffer supplied (FloatBuffer (f), IntBuffer(i), ByteBuffer(b)).

Some people here, myself included, have developed simple wrapper classes that restore the functionality as you described, I found this very useful when porting code from the many C++ OpenGL examples on the web.

These methods don't execute immediately, the information is only used when a glDrawArrays call is made, so if you use both color and texture, you need 2 buffers to hold the data, rather than just reusing 1.

I've now added private constructors to all OpenAL and OpenGL static classes in CVS.

- elias

This makes sense, but unfortunately it seems to break spgl's AL class, which subclasses the org.lwjgl.openal.AL class.

Although it is otherwise a static class, it seems Java still wants the spgl class to inherit the constructor from its superclass.

I'd suggest it would be better to either make the org.lwjgl.openal.AL constructor protected, so subclasses can still implicitly inherit it, or remove it completely, since it will never be called anyway.

Besides, about the buffers. I have a class for textures that (apart from all else) is capable of loading an image from a file. I have a field in this class that is aimed for storing the image information. And it's type is Buffer (superclass for ALL Buffers). It's very convenient to represent data this way, because this Buffer object can be an istance of either ByteBuffer, DoubleBuffer, FloatBuffer, or any other subclass. (as image data tends to be stored in various Java types). In C/C++ you can just have a void* field and it will be capable to store data of any type. But since we use Java, you can't store data in void array. So, what am I talking about? Well, it would be a LOT more convenient to use the Buffer superclass in all methods of LWJGL. Because if I had to use a subclass, I would do the following, which is a very nerve-racking task:

1 2 3 4 5 6 7

if(someBufferinstanceofByteBuffer)//pass it as a ByteBuffer argument

if(someBufferinstanceofDoubleBuffer)//pass it as a DoubleBuffer argument

etc.

But if LWJGL would have support for methods with Buffer only arguments, my code would be a lot shorter. And besides, this is how it's done in JOGL. So, why don't you check for the buffer type internally? I really hope you consider my advice!

Zeph: The GL* and AL* classes _are_ final! That's what they're meant to be anyway, so tell me if I forgot some (a few are not, like the ARBProgram class which is extended by ARBVertexProgram and ARBFragmentProgram. This is intended, and ARBProgran does indeed have a protected constructor (it has to)).

Orion: We've chosen not to use the instanceof "switch" in handling buffers. And LWJGL needs the specific type, because LWJGL, unlike JOGL, honors remaining() and position() (for which we need the element size of the buffer).

By requiring the client to provide a buffer of a known type. It is generally not advisable to provide methods that take a Buffer as a parameter because it could some crazy subclass of Buffer which you haven't anticipated such as CharBuffer or LongBuffer.

At the very least, require a ByteBuffer as your parameters, and then you can turn it directly into a FloatBuffer or IntBuffer or whatever as required. But Buffer as an argument is a very poor choice.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org