Ok i will check out the NIO api when i get the time. But i have to admit im not seeing the big picture for clueless newbes about using it IF we have to do specific JNI code. We could just ignore NIO a create our own JNI code that could be even more optimized for our game without the restrictions of having to suport NIO requirements.

It brings us to the question if having a direct binding to OpenGL and trying to patch the limitations of such aproach with packs like NIO is really a better option than creating a core native 3d engine independent of OpenGL and NIO and specialized to take advantage of Java OO features.

NOTE: When i say independent i mean not having to be one-to-one mapping of structures and functions from OpenGL to Java.

On a slightly related note, recently I had a bunch of data I was using for both rendering and game logic (a bunch or normals in particular). For ease I went with an array of objects for game logic use, and a nio buffer for use when rendering.

But duplicate data always annoys me. Do others tend to duplicate in this way or just use the nio data for both?

Ok i will check out the NIO api when i get the time. But i have to admit im not seeing the big picture for clueless newbes about using it IF we have to do specific JNI code. We could just ignore NIO a create our own JNI code that could be even more optimized for our game without the restrictions of having to suport NIO requirements.

Yup, your not getting it.

Let me take a step back l now that I *know* this is a clueless newbie discussion and explain. Lest start with Native Byte Buffers, just one of the NIO features:

In a typical Windows system running a Java application there are three very distinct and seperate hunks of memoy.

There is the device memory, an example of which being the memory on your video card that all geometry and textrues have to get to before you can render.

There is the C heap, which is the memory that the Java heap comes from as well as all memory you allocate in C from JNI.

Then there is the Java Heap, which is Java's memory. All data new'd in Java comes from the Java Heap.

In the worst case, using JNI, you would have to do the following to get geometry from Java to the video card:

For every Geomrtry Change:

(1) Allocate memory in the Java heap and build your geometry.(2) Call thorugh JNI (at some cost) to a C side function.(3) C side function calls back to Java to get the geometry. (Significant cost PLUS a full data copy from the Java heap to the C heap.(4) C function then calls an openGL function to set that in the video memory (ANOTHER data copy operation ocurrs.)

Now OGL, thansk to Nvidia, now supprots a way to get a "window" into the video card's memory and write to that directly from C. Using this you could eliminate step 4 by pre-allocating that window and then passing THAT to Java to copy the data into in step 3. This however does nothing about the really expensive part., which is moving the data from the Java heap to the C heap.

NIO introduces Native Direct Byte Buffers. These are sturctures that look like Byte Buffers from the Java side but are really pointers directly into the machine's memory space.

Combining the vdieo card geoemtry "window" and a native byte buffer, the code looks like this

ONCE:(1) Call throgh JNI to a C function that gets that video card memory window and wraps a Native Direct Byte Buffer around. It then returns the Natvie Direct Byte Buffer to the Java function that called the Native function, (Modest cost).

For every geometry change.(1) Write the geoemtry DIRECTLY into video memory from Java using the NDBB.

<do whatevr else you want to set up render>

(2) Call a JNI function once per frame that requires no data and returns no data. All it does is kick the card to render whats already been set into it.

See? You avoid MANY data copies as well as pulling data from the Java heap to the C heap which is quite expensive in of itself.

Quote

It brings us to the question if having a direct binding to OpenGL and trying to patch the limitations of such aproach with packs like NIO is really a better option than creating a core native 3d engine independent of OpenGL and NIO and specialized to take advantage of Java OO features.

In short, yes it is.

Your going to have to talk to OGL anyway. And if you use the features of Java correctly its really not appreciably more expensive then calling OGL from C.

And the more code you can do in java, the more portable you are, the less buggy you are., the faster your project is done, and the happier you will be

Quote

NOTE: When i say independent i mean not having to be one-to-one mapping of structures and functions from OpenGL to Java.

It isnt a one to one mapping on the code level. There is a mapping on the API level because the OGL API is proven and there is a huge body of knowledge on how to use OGl effectively already in existance.

But the assumption that every JOGL API call just calls the matching C API call across JNI in a dumb fashion is patently false.

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

It isnt a one to one mapping on the code level. There is a mapping on the API level because the OGL API is proven and there is a huge body of knowledge on how to use OGl effectively already in existance.

But the assumption that every JOGL API call just calls the matching C API call across JNI in a dumb fashion is patently false.

I've always thought that there were a 1:1 mapping. Whenever you a call a glXXX function, there is a JNI function call. Maybe a little book keeping for the more advanced features like vertex arrays or vbos, but always a JNI call.

Can you explain a little more what is actually going on behinde the scene? Are the functions cached in some way or what?

Let me take a step back l now that I *know* this is a clueless newbie discussion and explain. Lest start with Native Byte Buffers, just one of the NIO features:

In a typical Windows system running a Java application there are three very distinct and seperate hunks of memoy.

There is the device memory, an example of which being the memory on your video card that all geometry and textrues have to get to before you can render.

There is the C heap, which is the memory that the Java heap comes from as well as all memory you allocate in C from JNI.

Then there is the Java Heap, which is Java's memory. All data new'd in Java comes from the Java Heap.

In the worst case, using JNI, you would have to do the following to get geometry from Java to the video card:

For every Geomrtry Change:

(1) Allocate memory in the Java heap and build your geometry.(2) Call thorugh JNI (at some cost) to a C side function.(3) C side function calls back to Java to get the geometry. (Significant cost PLUS a full data copy from the Java heap to the C heap.(4) C function then calls an openGL function to set that in the video memory (ANOTHER data copy operation ocurrs.)

Now OGL, thansk to Nvidia, now supprots a way to get a "window" into the video card's memory and write to that directly from C. Using this you could eliminate step 4 by pre-allocating that window and then passing THAT to Java to copy the data into in step 3. This however does nothing about the really expensive part., which is moving the data from the Java heap to the C heap.

NIO introduces Native Direct Byte Buffers. These are sturctures that look like Byte Buffers from the Java side but are really pointers directly into the machine's memory space.

Combining the vdieo card geoemtry "window" and a native byte buffer, the code looks like this

ONCE:(1) Call throgh JNI to a C function that gets that video card memory window and wraps a Native Direct Byte Buffer around. It then returns the Natvie Direct Byte Buffer to the Java function that called the Native function, (Modest cost).

For every geometry change.(1) Write the geoemtry DIRECTLY into video memory from Java using the NDBB.

<do whatevr else you want to set up render>

(2) Call a JNI function once per frame that requires no data and returns no data. All it does is kick the card to render whats already been set into it.

See? You avoid MANY data copies as well as pulling data from the Java heap to the C heap which is quite expensive in of itself.

In short, yes it is.

Your going to have to talk to OGL anyway. And if you use the features of Java correctly its really not appreciably more expensive then calling OGL from C.

And the more code you can do in java, the more portable you are, the less buggy you are., the faster your project is done, and the happier you will be

It isnt a one to one mapping on the code level. There is a mapping on the API level because the OGL API is proven and there is a huge body of knowledge on how to use OGl effectively already in existance.

But the assumption that every JOGL API call just calls the matching C API call across JNI in a dumb fashion is patently false.

Well look at that, a simple explanation that compreensibly justifies the use of nio and jogl for games instead of a split c++engine/java solution. See guys it can be done.

The right information to the right people can do wonders in selling java game technology to the sceptics.

You guys have to try and fill the shoes of guys like me who have some knowledge of game design and mostly C++ but very little about how the Java solution works. Just telling someone like me to read the entire NIO doc and JNI doc wont cut.

It may sound too sceptical and unaceptable for some but the way many other potential java game developers see it if a developer can't cleary answer critical questions like this in a small document that can be understood by outsiders with a minimal knowledge of java gaming tech it will be taken as immature technology. Only after that they will pick up java gaming tech and test it.

When i say try it i mean buidling a prototype game both in C++ and in Java and do extensive benchmarks to catch all strong and weak points.

Thanks Alf. That was a very good explanation. I think you should pin it in the somewhere or make a blog of it.

I would have done that sooner I was just a bit confused by where the post was. The Performance Tuning category is generally a failry advanced topic and those entering it usually know a fair bit about Java and its worklngs already.

Once I understood where the touch-point really was I could do a much better job of explaining I'm glad it helped!

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org