Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (536)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Yours truly on Sun.com  (Read 3274 times)
0 Members and 1 Guest are viewing this topic.
Offline ChrisM

JGO Coder


Medals: 1
Projects: 1


END OF LINE.


« Posted 2004-12-22 02:32:47 »

Not to toot my own horn Roll Eyes ...but here I go Smiley

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

Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #1 - Posted 2004-12-22 05:06:57 »

@ 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  Wink

Offline ChrisM

JGO Coder


Medals: 1
Projects: 1


END OF LINE.


« Reply #2 - Posted 2004-12-22 10:38:14 »

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!
Legends of Yore - The Casual Retro Roguelike
Offline khashayar

Senior Newbie




www.agency9.se


« Reply #3 - Posted 2004-12-22 11:20:25 »

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

/Khashayar

Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #4 - Posted 2004-12-22 11:41:39 »

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.

Offline khashayar

Senior Newbie




www.agency9.se


« Reply #5 - Posted 2004-12-22 12:26:30 »

Well. I've heard these arguments before Smiley

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]

Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #6 - Posted 2004-12-22 13:02:20 »

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

Offline khashayar

Senior Newbie




www.agency9.se


« Reply #7 - Posted 2004-12-22 13:41:36 »

Quote

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.

Offline Spasi
« Reply #8 - Posted 2004-12-22 14:05:27 »

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.
Offline ChrisM

JGO Coder


Medals: 1
Projects: 1


END OF LINE.


« Reply #9 - Posted 2004-12-22 14:12:49 »

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

-ChrisM

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline JasonB

Junior Member





« Reply #10 - Posted 2004-12-22 18:31:17 »

Ugh.  Real Player.  Sigh.   Embarrassed
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #11 - Posted 2004-12-22 21:40:09 »

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

Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #12 - Posted 2004-12-22 21:41:49 »

Quote
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 Sad
Yeah, I figured that much Smiley

Offline khashayar

Senior Newbie




www.agency9.se


« Reply #13 - Posted 2004-12-23 10:11:50 »

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

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 Wink

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

Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #14 - Posted 2004-12-23 12:48:01 »

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

Cas Smiley

Offline khashayar

Senior Newbie




www.agency9.se


« Reply #15 - Posted 2004-12-23 14:18:41 »

Smiley

Offline Markus_Persson

JGO Wizard


Medals: 14
Projects: 19


Mojang Specifications


« Reply #16 - Posted 2004-12-28 13:05:05 »

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)

Play Minecraft!
Offline Middy

Junior Member




Java games rock!


« Reply #17 - Posted 2004-12-29 20:02:16 »

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

When do I get my makeMyGameAsILike() extension?
Offline karmaGfa

Junior Member




Miaow


« Reply #18 - Posted 2005-01-10 02:25:02 »

Quote
Had a bit of fun doing this


I like the music  Smiley

<a href="http://www.le-moulin-studio.com">Le Moulin Studio</a> - MMO Technologies and Services.
Offline Raghar

Junior Member




Ue ni taete 'ru hitomi ni kono mi wa dou utsuru


« Reply #19 - Posted 2005-01-11 18:57:55 »

Quote

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.)
Pages: [1]
  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.

CogWheelz (12 views)
2014-07-30 21:08:39

Riven (21 views)
2014-07-29 18:09:19

Riven (14 views)
2014-07-29 18:08:52

Dwinin (12 views)
2014-07-29 10:59:34

E.R. Fleming (32 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (42 views)
2014-07-24 01:59:36

Riven (42 views)
2014-07-23 21:16:32

Riven (29 views)
2014-07-23 21:07:15

Riven (30 views)
2014-07-23 20:56:16
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!