Yours truly on Sun.com

[ChrisM]

Not to toot my own horn ...but here I go

http://www.sun.com/directaccess

Had a bit of fun doing this and have links to Tribal Trouble and WurmOnline up on the site.

Cheers!

-ChrisM

[Matzon]

@ 3:20
"This is an engine build entirely in Java, using Java technology - and specifically the APIs Sun has released to the open source community"
Well, at least the last part was correct  

[ChrisM]

From Agency9's site:

"AgentFX™ 2 Platform is a high-performance platform-independent 3D-engine. The engine is used in a variety of products such as games and research studies about virtual environment. AgentFX 2 Platform uses the OpenGL API and is developed purely in Java."

Correct?

-ChrisM

Games published by our own members! Check 'em out!

[khashayar]

Yes, that is correct. AgentFX is developed in 100% pure Java.

The OpenGL API is available in Java through JOGL, LWJGL and maybe other projects. From the begining we used our own set of bindings. Currently we're using JOGL (offered by SUN). In the future we might use something else.

BTW Chris, thanks for mentioning Agency9.

/Khashayar

[Matzon]

What I meant to say that no matter how much of the game is done using Java - it still relies on something highly un-java such as a native component (JOGL, and probably also JOAL and perhaps JINPUT - or LWJGL). I know that any VM always uses jni stuff, but thats "different" since it's in the core distribution.

[khashayar]

Well. I've heard these arguments before

As I see it...

• OpenGL is a third party API.
  
• A third party API can be available for a VM or a language.
  
• So, OpenGL API is available for a variety of languages including for Java, C/C++ and Delphi. The OpenGL API is available for these languages without any regards to what language the OpenGL driver, for that specific hardware, is implemented in (Assembler, or some other hardware customized language*)
  
  For example neither OpenGL nor DirectX are distributed in any languages' "core packages". Let's take C/C++ as an example. The OpenGL API is an external API that is available for C through headers (in Object Oriented notation usually called interfaces). The same way the OpenGL API is available for Java through jni.
  
  That's why the guys at OpenGL are so meticulous on using the notation: "Written in C using OpenGL API" or "Written in Java using OpenGL API".
  
  [size=1]* Hardware customized languages are not that unusual in specialized hardware i.e. Set top boxes, mobile phones (Ericsson at least), etc
  [/size]
  

[Matzon]

As much as I would like to agree with you, I would hardly compare library header files with jni code.
at best you can compare that with interfaces.

Product in C -> Header file (no actual implementation) -> OpenGL

Product in Java -> Java code (which has the native method) -> JNI (Fat code, doing all sorts of magic) -> Header file -> OpenGL

[khashayar]

As much as I would like to agree with you, I would hardly compare library header files with jni code.
at best you can compare that with interfaces.

I understand how you see it. And to that extent I can agree with you that jnis are not completely comparable with header files. At least IF using "Fat code" in a jni. However I don't know about any projects seeing themselves as pure java projects, using the jni the way you describe it.

Any way... In this case, JOGL doesn't do any "magic tricks", neither did our previous set of binding that we wrote ourselves. All it does is simply translating com.agency9...A9GLVertex to GLVertex for use by the graphics driver. This is exactly what the OpenGL header files do for a C/C++ application.

And I might say that we don't really have a clue which language nvidia or ATI has used for writing their OpenGL drivers. So the "native" language in this case can be anything (although they are probably written in C). All we get is a C/C++ header pointing to the driver's object code (machine code).

Following this logical thread of discussion... It doesn't really matter if the OpenGL API is pre-shipped with the core packages of C/C++, Java or Delphi. It doesn't make the final application less Delphi, or less Java or even less C.

[Spasi]

I think the magic Matzon refers to is the jni code that both JOGL & LWJGL have, for displaying the OpenGL context contents, not the OpenGL API itself. Same for openal, input, etc.

With that said, in my mind if 100% of my project (not any libraries) is written in Java, it's 100% Java.

[ChrisM]

What I meant to say that no matter how much of the game is done using Java - it still relies on something highly un-java such as a native component (JOGL, and probably also JOAL and perhaps JINPUT - or LWJGL). I know that any VM always uses jni stuff, but thats "different" since it's in the core distribution.

Oh yeah, I would also say that if it were a technical program vs. a "concept" program, then I would be remiss in leaving out the depenances on OGL.  I should also point out that this was a 45 min interview whittled down into a 7min program, so some context is lost

-ChrisM

Games published by our own members! Check 'em out!

[JasonB]

Ugh.  Real Player.  Sigh.  

[Matzon]

Any way... In this case, JOGL doesn't do any "magic tricks" ... [snip] ...This is exactly what the OpenGL header files do for a C/C++ application.

No, JOGL does a HELL of a lot more than header files do!

Take the glMapBuffer method (ignoring the fact that it's an extension):
C Code:

1   2

glMapBuffer(...)    -> Native implementation (as per drivers)

Java Code (jogl, decompiled - couldn't be bothered to build):

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15

glMapBuffer(...)   -> Java implementation which involves:   1 - function lookup (long l = _context.getGLProcAddressTable()._addressof_glMapBufferARB;)   2 - check for function (if(l == 0L))   3 - allocation of array object (int ai[] = new int[1])   4 - call to glGetBufferParameterivARB (glGetBufferParameterivARB(i, 34660, ai);)   4.1 - JNI code performs mapping of direct buffers and other fun stuff (as needed)   4.1.1 - JNI code calls glGetBufferParameterivARB in Native iplementation (drivers)   5 - actual call to glMapBuffer (long l1 = dispatch_glMapBufferARB(i, j, l);)   5.1 - - JNI code performs mapping of direct buffers and other fun stuff (as needed)   5.1.1 - JNI code calls glMapBuffer in Native iplementation (drivers)   6 - sanity check   7 - generation of object of type ARBVBOKey (ARBVBOKey arbvbokey = new ARBVBOKey(l1, ai[0]);)   8 - branched lookup of cached byte buffer   8.1 - creation of bytebuffer for later use

As far as I am concerned, there is a LOT of magic going on behind the scene to make OpenGL work in Java
(LWJGL also does some work behind the scenes, though nowhere near that much!). However, this is the "extreme" case - most methods just take their arguments, and pass it to the gl method - and in that context it's almost the same. 'cept the java code, has some "fat" between the java stuff (which is activated at runtime) whereas C code using the GL header is all done at compile time.

[Matzon]

Oh yeah, I would also say that if it were a technical program vs. a "concept" program, then I would be remiss in leaving out the depenances on OGL.  I should also point out that this was a 45 min interview whittled down into a 7min program, so some context is lost

Yeah, I figured that much

[khashayar]

No, JOGL does a HELL of a lot more than header files do!

Well you are right in that. JOGL/LWJGL etc does more than just "header-filish" stuff to bring the OpenGL API to Java. However we probably have different views on where "magic" starts and ends. But that's a matter of taste I guess

I perceive JODE as a "magical" non-java package. All the calculations regarding the functionality of that package (physics) are done in C/C++ code and the JNI offers an interface to that package. Most of Java-games and engines that I've seen have their functionality written in Java. Take AgentFX 2 for example. All lighting, octree, portals, etc etc etc are written in Java. The only functionality that JOGL offers is to be just an interface for using the OpenGL API. Behind the scenes JOGL/LWJGL may do what is necessary to deliver the "interface functionality".
Who knows... In the future maybe Sun will include JOGL in the base VM package and everything's gonna be alright

Anyway... Gotta go try the Christmas lunch, and maybe have some "Gammeldansk"... But I guess that's a matter of taste too Merry Christmas folks

[princec]

maybe Sun will include JOGL in the base VM package and everything's gonna be alright

Hope not...

Cas

[khashayar]

[Markus_Persson]

Wheee, free plugs. =D

If you won't toot your own horn, I'll toot it for you! =D
(er, wait.. that came out wrong)

[Middy]

Great stuff Chris. Whats matters is that SUN takes the community seriously. :-)

[karmaGfa]

Had a bit of fun doing this

I like the music  

[Raghar]

Product in C -> Header file (no actual implementation) -> OpenGL

Product in Java -> Java code (which has the native method) -> JNI (Fat code, doing all sorts of magic) -> Header file -> OpenGL

product in statically compiled language - by definition file, or by hand, or by kernel call mapped to some library - library calling implementation - OpenGL do hard work - buggy driver call - GFX do work

product in Java - batch of data - JNI call -  by hand call mapped to some library - library calling implementation - OpenGL do hard work - buggy driver call - GFX do work

Not too much different. If someone does too much work in native code force him to use assembly.

Of course there are alternatives
product in assembly sometimes compiled language - batch of data, or so - ruber hose analisis of driver, or dissasembly analisis of driver - translation into GFX card data - moving into driver part of memory - direct call GFX do work

halfscript - preparation of calls - one time accepting by guard a certified multithreaded splitable driver - translation by driver - exclusive mode of card - GFX do work

Of course halfcript doesn't have a compiler.
The direct GFX microcode functions call by assambly is unatractive too. Too much work to do a window, and of course that ruber hose analisis.

So we are ending with inperfect solutions, for "perfect" games.



Just a few days ago I had a little proble with one demo program, it used a funny optimalizations and SSE functions. It compiled and worked well for my old CPU, but I was forced to disable all optimalizations to force it work on my new CPU. The most beautiful thing was when I used O2 G6 switch compiler returned optimalizations back in safer way. The point is the original compiled binary would refuse to work with my computer and many others, just becouse it did a work that could be JITed.

So if someone would try to be oversmart and use "crossplatform" portability of C to do a work that could be done by same amount of line of code, or less in Java at the simillar speed, he should carefully provide alternative and test his library (that would fail unpredicably)

So if you are doing batching in Java, you are faster than in C (if library connection wasn't done in a baka way). If you are trying to do batching in C, you are ending with unreadable code and possible library inter operability problems.

As a sidenote, you could be fast in both languages, but your performance could be killed by a buggy driver. That happens most often, when there is game like Doom 3 and both main GFX manufacturers are trying to be baka.


copyright Raghar 2005 permision to cite, use as part of your article, repair grammar, and add a half page of nasty words about both NVIDIA and ATI granted. (If that halfpage wouldn't be just insults you could add more.)