Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (120)
games submitted by our members
Games in WIP (577)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2]
  ignore  |  Print  
  What good is java.nio for?  (Read 6872 times)
0 Members and 1 Guest are viewing this topic.
Offline zingbat

Senior Duke




Java games rock!


« Reply #30 - Posted 2005-05-12 11:51:54 »

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.
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #31 - Posted 2005-05-12 12:16:25 »

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?

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #32 - Posted 2005-05-12 12:30:22 »

Quote

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


That's (one of the radically different and unrelated) reasons why you want structs Grin. Lets you keep your data in buffers and yet access it in java-friendly manner.

/me ducks and runs for cover

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #33 - Posted 2005-05-12 12:34:46 »

Well yeah, but I was kinda hoping for some practical advice which I can actually use *now*. Tongue

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #34 - Posted 2005-05-12 16:02:47 »

I duplicate data and tend to write it out sequentially in one big go to make best use of caches and write combining.

Cas Smiley

Offline Jeff

JGO Coder




Got any cats?


« Reply #35 - Posted 2005-05-12 19:03:15 »

Quote
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 Smiley


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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Jeff

JGO Coder




Got any cats?


« Reply #36 - Posted 2005-05-12 20:51:45 »

Quote

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


Modern games tend to keep at least two partially seperate representations of the 3D world in memory, even in C.  One optimized for render and another optimized for Physcis.

Does that help any?

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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #37 - Posted 2005-05-12 21:08:51 »

Yes, the more I think about it it seems unavoidable. A pretty classic speed vs. memory tradeoff really. And we all know which way games tend to lean in that department.

Thinking about it, what I should do is resign myself to keeping a duplicate - at which point I can optimise the for-renderer copy and shove them in vram where drawing will be faster.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline tom
« Reply #38 - Posted 2005-05-12 21:58:55 »

Quote

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?

Offline zingbat

Senior Duke




Java games rock!


« Reply #39 - Posted 2005-05-12 23:55:22 »

Quote


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.


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 Smiley



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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Jeff

JGO Coder




Got any cats?


« Reply #40 - Posted 2005-05-13 04:19:01 »

Thank you Smiley

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 Smiley  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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Pages: 1 [2]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Longarmx (52 views)
2014-10-17 03:59:02

Norakomi (43 views)
2014-10-16 15:22:06

Norakomi (33 views)
2014-10-16 15:20:20

lcass (37 views)
2014-10-15 16:18:58

TehJavaDev (68 views)
2014-10-14 00:39:48

TehJavaDev (66 views)
2014-10-14 00:35:47

TehJavaDev (59 views)
2014-10-14 00:32:37

BurntPizza (73 views)
2014-10-11 23:24:42

BurntPizza (45 views)
2014-10-11 23:10:45

BurntPizza (86 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!