LWJGL Forum

Support for String arguments and return values has been added to LWJGL:

- Existing methods have been overloaded, your current code will run unmodified.
- Return values are Strings, input values are CharSequences, so you can also use String, StringBuilder or any other implementation.
- Support for CharSequence[] arguments is also included.
- The implementation uses ThreadLocal buffers internally, so it's multi-context ready.

Some examples:

glShaderSource(int shader, ByteBuffer string); // Original
glShaderSource(int shader, CharSequence string); // New - single source
glShaderSource(int shader, CharSequence[] strings); // New - multiple sources

void glGetShaderInfoLog(int shader, IntBuffer length, ByteBuffer infoLog); // Original
String glGetShaderInfoLog(int shader, int maxLength); // New

----------------------

EDIT: I have extended this API feature to primitive types. Functions with Buffer arguments that often read or write a single value in those Buffers have been overloaded to accept or return that single primitive value. Examples:

int texID = glGenTextures();
glDeleteTextures(texID);

int maxTexUnits = glGetInteger(GL_MAX_TEXTURE_UNITS);
float aniso = glGetFloat(GL_MAX_TEXTURE_MAX_ANISOTROPY_EXT);

if ( glGetShader(shaderID, GL_COMPILE_STATUS) == GL11.GL_FALSE ) throw new RuntimeException();

----------------------

EDIT2: Added a javadoc comment to all the new methods that says which GL call is being overloaded.

----------------------

I would very much appreciate it if you could download a nightly build (https://www.newdawnsoftware.com/hudson/view/LWJGL/) and try it out in your projects. Let me know if something doesn't work or if I have missed any functions that could be overloaded.

Fancy adding conveniences for glGetInteger etc. too?

Cas :)

It's what I'm doing the past two days. ;)

Support for primitive parameters and return values has been added, I've updated the first post with examples.

Wow, that's all looking great. I'll check the nightly when I have a moment

Quote from: Rene on March 15, 2010, 13:49:01
Wow, that's all looking great. I'll check the nightly when I have a moment

Right, I just checked some of the new functions, and it all works like a charm. This cleans up my code quite a bit! Thanks!

I agree, this looks like a welcome change. :)

Lovely stuff. Any chance of this rolling across to the OpenAL side too?

I've added some AL functions, should be available on the next nightly. They are only 6 though, 4 Gen/Delete ones and the two alSource(Un)QueueBuffers. The rest of the API already has alternate function versions for single values, unless I missed something.

Even lovelier stuff! GLUtil.scratch buffer begone!

Great change. Hope this doesn't complicated the auto JNI stuff for you devs however. We don't want to give you too much work and put you all off the project.

This is damn great.

Would be nice to have some additional stuff for getActiveAttrib/Uniform to get rid of those pesky IntBuffers... glGetActiveAttribType and glGetActiveAttribSize maybe?

Cheers,
E1.

Quote from: EvilOne on March 23, 2010, 07:59:27Would be nice to have some additional stuff for getActiveAttrib/Uniform to get rid of those pesky IntBuffers... glGetActiveAttribType and glGetActiveAttribSize maybe?

Done, added glGetActiveUniformSize, glGetActiveUniformType, glGetActiveAttribSize, glGetActiveAttribType. Could you please test it when the next build is up? I'm not sure how it's going to behave with a 0 maxlength passed to the native call. Btw, for uniforms a better choice would be glGetActiveUniforms(int program, int uniformIndex, int pname) in GL31 and ARB_uniform_buffer_object.

I've also added a javadoc comment to all the new methods, so that it's easy to tell which GL method it overloads. It can be quite messy without it in some cases.

Hi

Thanks for the new methods, they clean up the code nicely. Any chance of getting glGetActiveUniformBlock added aswell?

Thanks & Regards
elFarto

Thanks, glGetActiveUniformBlock was ok in ARB_uniform_buffer_object but missed it in GL31. Gonna add it when I commit the APPLE extensions.

Thanks for that.

Is there any plan for improving the native implementation of those methods? Currently you use the original method that expects a IntBuffer to be passed in, but when dealing with, say glGetTextures, you can write the native implementation like:

GLint foo;
glGenTextures(1, &foo);
return foo;

This would presumably be faster/more efficient as you wouldn't need to manage the buffers.

Regards
elFarto

We already have support for this (see the 6 new methods in OpenAL) and I did consider doing it for OpenGL too. The problem is that it would require a new native implementation for each alternative method and, based on some quick calculations, it would add 80-90 kb to LWJGL's native binaries. Along with the fact that all these methods are not performance sensitive, I decided it wasn't worth doing. LWJGL is already getting bloated with all these new extensions coming out every 6 months, I thought it will be important for web-deployed apps that LWJGL stays small in size.

In any case, this was a personal decision and can be changed easily if the community decides otherwise.