As LWJGL forces us to wrap everything in floatbuffers and then flip them (endian issue?), it would sound logical if datatypes that come with LWJGL also provide this function internally.
Maybe I have not looked hard enough but I could not find a Matrix4f.asFloatBuffers() method. I realize doing this manually is not a big deal, it would simply (re)move some redundant code in the project code itself.
In my example the Matrix classes do have a "store" method but it still requires us to manually create the floatbuffer up front.
Also an asFloatBufferFlipped() method of course.
You can use Matrix4f.store(FloatBuffer).
Also, Buffer.flip() is for flipping the mark and the size.
The mark is marking the current position in the buffer (see put()), and when you finished putting things into the buffer, you call flip(). This will make the mark to be reset, and the size to be set to the mark :)
EDIT:
Though there are endian "issues", the name for "flipping" the endian order, is setting the native byte order, see order().
EDIT2:
Oh, and FloatBuffers are not the LWJGL ones anyway. We don't have permission to change them. They're in java.nio from the Java SE.
The "enhancement" I'm suggesting is add a Matrix.asFloatBuffer() method which would return that Matrix object already wrapped in a FloatBuffer. Creating your own FloatBuffer and "storing" or "putting" the values in that floatbuffer manually is just extra code that doesn't really do anything useful. (And if your adding a asFloatBuffer you could also do an asFloatBufferFlipped)
EDIT: these "asFloatBuffer" methods could be added to any other datatype that LWJGL provides, I've only been using the Matrix classes - don't know if there are others. The idea is to eliminate the need to manually create a floatbuffer and push it to somewhere behind the scenes.
Is it really that hard to do:
FloatBuffer buffer = BufferUtils.createFloatBuffer(16);
matrix.store(buffer);
?
Also, as matheus23 said, flipping doesn't have anything to do with endian-ness. It has to do with how the NIO Buffers are designed. A correction on matheus23's post, it doesn't change the mark, but the position. The mark is a separate variable. When flipping, it does is place the limit at the current position and the position at 0 so you can go in and read them data in order.
It does not matter if it's difficult or not, it's just cumbersome. Again: if you are forcing us to use wrappers for data going to OpenGL/AL/... why not also provide the methods for getting the data in the proper format in the first place. This has nothing to do with how easy it is to do it yourself. I do not understand why you would not provide such functionality out of the box.
If you are creating floatbuffers in this manner you are probably going to abuse them. Well, I say "you" but I mean a typically uninformed Java games programmer who doesn't understand buffers and the JVM.
Buffers should be created extremely sparingly; usually right at application startup. And then reused continually. Not just little dribs and drabs created all over the place. I can understand that creating a few little ones for one-off operations is handy and indeed a method to do that bit of boilerplate for you seems logical but then we'll get some fool doing it 100x in every frame and complaining about the mysterious performance problems and out of memory error.
Cas :)
Because I don't see the point of having an asFloatBuffer method that creates a new FloatBuffer instance. Since you will want to upload a matrix many times, the store method can be used many times for the same FloatBuffer instance.
EDIT: grr princec stole my thunder :P
Ok, well now it makes much more sense for not including that functionality in the first place. I am an uninformed "java game" programmer, so saying "you" is correct ;).
Aha :)
Well, there you have it in a nutshell then: create your Buffers once and reuse them. Werd!
Cas :)