I can see why this isn’t going to go down hugely well, but do you think the addition of direct array support in LWJGL would be a wise move? I know that they are slower, generally, than their native mapped buffer counterparts, but overloading things like color3fv with an array version gives people a choice (though of course it might lead to people using these exclusively).
I don’t know, passing array references just seems more natural that’s all.
It certainly is natural, unfortunately it’s naturally really slow too, so we won’t be adding it. Besides - you are certainly better off in Java doing
gl.color3f(color[0], color[1], color[2]);
than
gl.color3fv(color);
The syntax you see is a bit of a C anachronism.
I’m still not even sure we should be using pointers myself but there’s still a huge overhead getting an address out of a direct bytebuffer using JNI methods. More experimentation needed.
Cas 
I understand why you don’t want to add them. I wrote this when I was originally thinking of moving from GL4Java to LWJGL. Now that I decided to go with it anyway I’m kinda getting used to it, or just sticking with using Xf rather than Xfv for funtion calls in some areas of code.
On a different note though since I’ve noticed that they are in the examples and I’ve stuck them in the code that I’m using should LWJGL have a utility library for generating float buffers (or any other type of buffer) we could use an OpenGL like syntax and have something like:
public static FloatBuffer floatBuffer3f(float, float float)
{
//generate and return the float buffer with the values given
}
and give “overloaded” forms for arrays and other common sizes (well four points I guess).
Let me know what you think, I’d be happy to write them, though it is hardly much work and it could be stuck in a package like org.lwjgl.util or something.
We had a little discussion a while ago about abstracting the “int pointers” away with a safe data-type wrapper. I think the general consensus was that it would add a load of classes to LWJGL, add a load more method signatures and add a lot more maintenance issues, and not help out all that much. If you’re careful you should have no problems with ByteBuffers, they just take a bit of getting used to.
They’re a bit of a waste for storing small amounts of data like single vertices anyway. At least with the current JVMs they appear to be page-aligned, so each vertex will take up 4K of RAM… :o
However, a few functions to automate the creation of ByteBuffers might be useful. It would certainly stop people forgetting to multiply their calculated size by four for 32-bit data types, or forgetting to set native ordering etc. Sys looks a good place for them - any thoughts?
public FloatBuffer createFloatBuffer(int size)
public FloatBuffer createFloatBuffer(float[] data)
etc
This is for the devs of lwjgl, mainly cas:
What do you guys plan on doing with the buffers? I mean I know only one use for the buffers, but wouldn’t it be a bit nicer for even the syntax of the code to hide the Sys.getDirectBufferAddress(buffer), since it does not serve any real purpose, at least not to my knowledge.
It is just a minor thing and not really that important, but I just need to ask does it serve any other purpose?
(I’m not an LWJGL dev, but I’d like to chime in here)
The reason for using buffers is to pass chunks of data to OpenGL via the LWJGL JNI layer. The various methods that access or fill buffers with data could take a ByteBuffer object directly, but getting the data out in JNI-land would then be quite expensive.
It’s a lot cheaper to just generate the address Java-side and cache it somewhere. Sys.getDirectBufferAddress does that generation.
For the record, we have been talking about doing a MemoryBuffer object instead, which is just a ByteBuffer with its chached address. That way:
a) it’s “easier”
b) (most importantly) more safe.
Some have been arguing against lwjgl, exactly because you could wreak havoc with those pointers. By making lwjgl safe (and NOT making it abysmal to work with) we will make the library available to a whole other group of people.
This hasn’t been thought 100% through yet, so no promises here…
I know what it is for, perhaps I wasn’t clear enough. Can’t the sys.getdirectbufferaddress be hidden somewhere into the code? Since it doesn’t seem to have any other purpose than passin in the buffer address, why can’t it be hidden somewhere into the code?
I thought that was included into the principles of clear syntax. If it is trivial and does not have any other purpose, then why is it there? It just makes things one step more complicated. I mean if there as a good reason, for the user to use it in that form, then it should be in that form. If there isn’t, couldn’t it be included somewhere else?
Sys.getDirectBufferAddress is out of place and looks nasty in the code.
I think I understand what you mean.
If MemoryBuffers are implemented, then it will disappear from your code. You instantiate a memory buffer, the constructor gets the address and stores it, and when you pass the MemoryBuffer to a method it either calls the “pointer” version of the method with the address of the buffer wrapped in the MemoryBuffer, or it passes the whole lot to JNI which then extracts the address and uses it. It’s a bit more overhead for the library, but it removes that from the developer.
Currently you can’t do without getDirectBufferAddress, as you need to do the caching. Passing a ByteBuffer to a method and making it get the buffer’s address each time is too costly. However, until MemoryBuffer appears (if it ever does) for now you can just implement your own wrapper for ByteBuffer, as I’m sure many of us have done so. Used like:
gl.getIntegerv(GL.WHATEVER, myBuf.getAddress()) ;
Call getDirectBufferAddress in the constructor, cache it as an instance variable and implement a getAddress method to pull it out. The address is then held with the data, you’re less likely to get things mixed up, and the “ugly” method call disappears from all your code except the wrapper. Tada! ;D
Would the replacement buffers subclass the current nio classes, or would you create another native allocation system. If the 4k minimum allocation is true (and I have no reason to accuse cfmdobbie of being a lier) then ByteBuffer is really quite expensive.
As for the buffer creation utility class I was thinking of the package being org.lwjgl.util and the class Buffer with static functions for creating a three and four value buffer for the most regular types taking both seperate values as an argument and arrays as an argument. There would also be a function to create an arbatary length buffer and one to create an arbatary length buffer based on an array handed in. An example of the basic format would be:
createFloatBuffer3f(float, float, float)
Basically the same format as that used in OpenGL.
[quote]If the 4k minimum allocation is true (and I have no reason to accuse cfmdobbie of being a lier) then ByteBuffer is really quite expensive.
[/quote]
I can’t take credit for that piece of info. There was a thread a while back which discussed ByteBuffer overheads, and it was Cas who put two and two together:
Naturally, this behaviour may change in a future Java release.