Buffer argument to retrieve a single value

OpenGL Development
#1

Howdy all,

Reading the following thread ( http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jogl;action=display;num=1106324571 ), i’ve come to think about the way gl functions are meant to be used and the way they can be use with lwjgl.



// c code

int textureName;
glGenTextures( 1, &textureName );

// java + lwjgl code

IntBuffer textureNames = BufferUtils.createIntBuffer(1);
GL11.glGenTextures( textureNames );
int textureName = textureNames.get(0);

Well … a bit messy isn’t it ?

Is there any hope to see a method like int glGenTextures() in GL11 ?

The same is true for some other gl functions like glGetInteger, glGetDouble, etc.

Regards.

#2

From the LightWeightJGL site:

[quote]LWJGL is not meant to make writing games particularly easy; it is primarily an enabling technology which allows developers to get at resources that are simply otherwise unavailable or poorly implemented on the existing Java platform. We anticipate that the LWJGL will, through evolution and extension, become the foundation for more complete game libraries and “game engines” as they have popularly become known, and hide some of the new evils we have had to expose in the APIs.
[/quote]
I wouldn’t mind sth like that in LWJGL, but if we were to do it for tex ids and glGet methods, where would we stop? Besides, you shouldn’t bother doing such things in every place necessary. Just hide the functionality in a static/factory method and forget about it.

#3

glGenTextures can return more than just a single int though, so really it needs to return an int[].

But while you could easily convert that function, glGet* calls return either an int or an int[] (or double, etc.) depending on their args. I suppose you could write a couple of versions that wrapped the LWJGL version and which checked the args were suitable, but it would be a bit of a pain to check all the possible arg values.

#4

[quote]glGenTextures can return more than just a single int though, so really it needs to return an int[].
[/quote]
I was thinking about two overloaded methods, void glGenTextures( IntBuffer ) and int glGenTextures()

Good point. Maybe something like that :


// naive jni implementation of glGetInteger

  GLint[16] params;

  glGetInteger( pname, params );

  return params[0];

Regards.

#5

Yep. We tend to stuff things like that in utility classes, leaving the core LWJGL true to what it’s meant to be, just the minimum needed to do the job.

Cas :slight_smile:

#6

So, in the Utility classes (if you don’t want to modify the core) please can’t you put the following:

glReadPixels()
glTexImage2D()
glTexSubImage2D()
glDrawPixels()

with java array arguments (will use get/releaseArrayCritical)

It’s just 10 minutes of coding and it will be of great help for those “offscreeners” like me. More seriously it will avoid pre-allocation of NIO buffers and a number of memcopys per animation loop (imagine you want to update the bufferedimage contents).

Many thanks.

Mik :wink:

#7

Why don’t you do it :)?

Cas :slight_smile:

#8

No problem for me.

Can I modify the LWJGL src and submit it to you ?

#9

It sounds more like an addon to me than a modification. Separate package, separate DLL sort of thing (or optionally compilable into the core DLL, like FMOD is)

Cas :slight_smile:

#10

well, this was the second choice.
The first one is to have these features inside LWJGL.
I didnt want to create another dll for such a LWJGL-related thing.

The best way is that you consider the benefits of the above mentioned methods (I’m sure you already have considered it) and you put them inside LWJGL…

Anyway, I’ll take a look at FMOD and I’ll write the extension. Sorry for my ignorance, but… will it (the extension) be distributed with the official LWJGL ?

#11

[quote]Yep. We tend to stuff things like that in utility classes, leaving the core LWJGL true to what it’s meant to be, just the minimum needed to do the job.

Cas :slight_smile:
[/quote]
Still, allocating a direct buffer to retrieve a simple scalar sounds weird and inefficient to me ( maybe i’m wrong =).

#12

What the various utility classes around do that people have made is statically allocate one little buffer for stuffing such values in, and then using it for all subsequent calls.

Cas :slight_smile:

#13

The SGLUtils are up and running! Some extra FPS more, simpler code and no NIO buffers around…

Implemented:


      native public static void glReadPixels(int x, int y, int width, int height, int format, int type, byte[] pixels);
      native public static void glReadPixels(int x, int y, int width, int height, int format, int type, int[] pixels);
      //
      native public static void glDrawPixels(int width, int height, int format, int type, byte[] pixels);
      native public static void glDrawPixels(int width, int height, int format, int type, int[] pixels);
      //
      native public static void glTexImage2D(int target, int level, int internalformat, int width, int height, int border, int format, int type, byte[] pixels);
      native public static void glTexImage2D(int target, int level, int internalformat, int width, int height, int border, int format, int type, int[] pixels);
      //
      native public static void glTexSubImage2D(int target, int level, int xoffset, int yoffset, int width, int height, int format, int type, byte[] pixels);
      native public static void glTexSubImage2D(int target, int level, int xoffset, int yoffset, int width, int height, int format, int type, int[] pixels);