[CLOSED] toBuffer methods for converting arrays to buffer

[Chuck]

I whipped up some quick methods for creating direct buffers from their corresponding array types.  They might make a good addition to BufferUtils.  Here they are on my BufferUtils2 class, which you can find at https://bitbucket.org/chuck/lwjgl-sandbox/src/tip/src/main/java/sandbox/util/BufferUtils2.java

I'm on the fence about whether they need to be polymorphic and all have the same name, or if naming them "toFloatBuffer", "toByteBuffer" etc would be clearer.  Either way it's going to be typesafe since the return value is invariant with the array's type, but using different names might fit BufferUtils' existing conventions better.  Long as there's a quick way to convert arrays to buffers, I don't really care either way.

[kappa]

IMO the above is a really nice idea and would make a nice addition to BufferUtils, should remove one of the pain points in using LWJGL.

Was porting some code today and its a pain to have to do an extra

FloatBuffer floatBuffer = BufferUtils.createIntBuffer(floatArray.length);
buffer.put(floatArray);
buffer.rewind();

everytime data needs to be passed to LWJGL, should help make lwjgl code shorter and cleaner.

p.s. really love using Spasi's last changes to the shader methods (allowing Strings to be passed) and the overloading methods, really makes everything nicer.

[spasi]

I know these methods are convenient and sweet, but I wouldn't want to encourage their usage. It's an allocation and a copy on every call, this could potentially kill performance if used naively. I have personally always used buffers directly instead of arrays, or at least used pre-allocated and cached buffers for the copy + GL call. Using a memory allocator on a big ByteBuffer that .slice()s small buffers out of it is also a common practice. We even have mapped objects in 2.8 that should be more convenient and efficient than using arrays/buffers.

With that said, I don't mind adding these methods to BufferUtils if there's enough interest.

[kappa]

I know these methods are convenient and sweet, but I wouldn't want to encourage their usage. It's an allocation and a copy on every call, this could potentially kill performance if used naively.

Ah that's a good point, didn't think of the potential abuse that could happen. Having said that, those that don't understand how buffers (or allocating memory) work will probably be allocating buffers every frame anyway with or without these methods (without they'll just have a few extra lines of code ).

However often it is hard to avoid using normal java arrays when working with java especially when porting code or following tutorials. I think by putting a stark warning in the javadoc of the dangers of using the methods (and how they should only be used once on initialisation or something) should help clarify their use and go someway to avoid such misuse. On the plus side they should make LWJGL code and samples look much nicer and shorter. Its only a bit of syntactic sugar (just like the rest of the methods in BufferUtils) which removes some of the ugly long syntax required to use buffers.

[Chuck]

Using this in a literal syntax means amortized overhead of zero.  To wit:

FloatBuffer lightAmbient = toBuffer(new Float[] { 0.5, 0.5, 0.5, 1.0 });

Now if you're talking about adding an OO API that does for other objects what Slick's Texture does for textures, then I certainly won't argue against that, as long as there's a literal syntax (i.e. constructor or factory) that lets me see what the value is in the code without a bunch of boilerplate .put()s and .flip()s

[princec]

Hm, I'm generally opposed to API cruft appearing. I've probably already got a utility that does this and I'd also probably never find out about it being in LWJGL if I were a typical user of LWJGL.

Cas

[Chuck]

You have a utility, I have a utility, I bet a dozen other people have a utility.  The name of the class is BufferUtils.

Anyway I'm not going to die on this hill, but if you really want the most minimal binding, I recommend C.