What about performances

Hi,
First of all, sorry for my english, because i’m a french man.

I’m very interested in java games development, using OpenGL. But i’ve some questions on JOGL :
1/Does Jogl really provide acces to OpenGL as well as nearly all vendor ? JOGL supports fully OpenGL 2.0 ?
2/Does Jogl support the OpenGL Langage Shaders (GLSL) ?
3/What about the performances of Jogl ? I suppose it couldn’t be as fast as opengl used with the C langage but is it sufficient fast to make by exemple 3D animations or 3D Games ?
Or must i take a look on LWJGL, which is supposed to be faster because of using NIO instead of arrays ? But i don’t like the C-style of this API…

Must i learn the two APIs ? And maybe make an abstraction layer to permit the use of the more working API on the user computer and his OS ?

And an other questions, but i don’t if it’s better to ask it in the tools forum, how can i add the javadoc of jogl in Eclipse ? I’ve tried with right-clic on the jar => properties => javadoc location => javadoc in archive => archive path to the zip and path within archive to “javadoc_public”, then validate and apply but it doesn’t work…
On the editor, when i focus a function, or a class of JOGL, it tells me " xxx cannot be resolved".

Thanks a lot for answering !

This is the second or third time I’ve seen this claim:

[quote]But i don’t like the C-style of this API…
[/quote]
Could someone enlighten me as to the difference in calling:

GL11.glBegin();
and
gl.glBegin();

???

Just because you pass around an object in JOGL doesn’t make it any more OO than LWJGL

I think the difference is obvious, capitalisation and the number 11 - oh, and I suppose the static nature of the call.

Kev

But it IS a static API… and with Java 5.0 you do import static GL11.*; anyway…

Cas :slight_smile:

Hey! I was just answering the question :slight_smile:

Kev

Sorry…but i’ve heard some persons saying that, so…
What’s disturbing me with LWJGL is that’s not an official API from Sun, and i’ve heard that Jogl may be included in the JRE in the future.
LWJGL is also an API for OpenAL, and I only want an API for 3D, not more, but which makes his job well. I want an API which is as near of the official OpenGL API as possible. I want something with i can say that i make opengl, and that i can use the Opengl tutorials even if they’re not for Java.

So, if Jogl will be supported by Sun and developped and improved during a long time (not as Java3D…), and if his performances will increase at each new versions, it can be the best API to learn, no ?

Thanks for your answers, but can you help me too for the first 3 questions and maybe the last one with eclipse ?

Oh sorry, i’ve an other question :-[

My problem isn’t to install or to join this API or that API. My problem is that i don’t want to learn two different API to do the same things.

But if those both APIs (Jogl and LWJGL) are very similiar, especially in the name of the functions and the how the make graphics, i can use bothes, no ?
Maybe i can make an abstraction layer, and give to the user the choice of the API.
Because, in fact, the both are OpenGL no ? So they must very similiar…Or i comit a mistake ?

Sorry if you can’t understand very welle what i say, but i’m an non-english speaker…

"Sorry french for help the poor lost guy :slight_smile: "
C’est ce que fait jME : www.jmonkeyengine.com c’est une couche de plus haut niveau a terme tu pourra choisir entre LWJGL et Jogl. Si ton but c’est de faire un jeu, n’hésite pas LWJGL est beaucoup mieux (gestion des fenêtres, du timer, du déploiement). A mon avis jogl ne sera jamais intégré dans le JDK de Sun (car viole l’idée de la sandbox car tu peux planter le PC avec OpenGL). De plus LWJGL a une syntaxe intéressante (les import statique) pour porter des exemple en C vers Java.

They are almost identical, with a very slightly different approach to doing exactly the same thing. LWJGL is very well supported (and has been around for somewhat longer than JOGL too). Who knows, maybe one of these days it might end up on java.net too.

LWJGL manages to squeeze in OpenAL for free; you don’t need to include it though. Just leave out the packages and dll… we just package it all up for convenience.

Cas :slight_smile:

Thanks men :slight_smile:
Héhé merci beaucoup vrm :wink: Mais je vais continuer en anglais (malgré mon niveau) car on malgré tout sur un forum anglais :).

Xith3D does the same (the same of jME) no ? Or maybe will do the same, but with an higher level of abstraction…
But i don’t want to use an high level API, i’m a beginner in 3d with Java, and probably even in 3D, so i want to start with the basics…i don’t want to start at an too high level of abstraction, because i will never learn the base…
And i want something +/- light.

For the instant, my aim isn’t to make a game, i want to be realistic. I will start with some small animation than some mini-games. But if the synthax and methods are almost the same for the two APIs, i can make a very light and small layer abstraction, for my own use, what do you thing about that ?

Jme and Xith are two different Scenegraphs. They abstract away OpenGL commands, provide a tree structure to manage your tree (Quad tree optimise culling). Provide model loading, animation, physics, game state (jme has one, not sure abotu xith), and entity systems (again, jme has one made by me, but it is not in the base).

Abstracting away from both jme and xith to make it “pluggable” is really just a waste of time since some have things the other doesn’t and it would be more performant if you just chose one. There really is no point in abstracting away the abstract. The syntax is not the same for both, and they have very different ideas about things. Xith is the same as Java3D but geared towards games, while Jme is based on NetImmerse which is a commercial engine used for numurous games (now called Embryo), jme itself is free under the BSD license.

Whats so not realistic about making a game? Im making one and alot are…you just have to be determined and very self-motivated.

Hope that helps and sheds some light in your decision.
DP

Thanks for your answer but my choice is between two lower level API : JOGL and LWJGL.
And i wants to know if the synthax and methods are almost the same for the two APIs, i can make a very light and small layer abstraction, for my own use, what do you thing about that ?

When i say i want to be realistic, that’s doesn’t mean that games development (so long they are reasonable) are no realistic but if i say that i want make a MMORPG 3D in 3 months, whereas i’ve never programmed in Java…that’s not realistic. It isn’t my case, but i’ve never made 3D and so less 3D in Java. So i’m realistic in saying that i won’t be able to make a games (not a mini-games) quickly.

But of course, make games alone, so long they aren’t too big, is completely possible.

It’s entirely possible to make an abstraction between the two APIs… but probably a waste of time.

If you just want to dive in and start playing with OpenGL, use LWJGL. It’s ultra-simple. We especially designed it for this.

Cas :slight_smile:

1, 2) Don’t know fore sure, but both JOGL and LWJGL is updated regurarly. If they don’t already support OpenGL 2.0 and GLSL, they probably will in the very near future.
3) JOGL and LWJGL is about equaly fast. There is a tiny JNI overhead when calling native functions, but nothing to worry about. That said, getting the best performance out of OpenGL, in c or Java, requires alot of knowledge.

Thanks. So LWJGL is OpenGL as JOGL.
If i learn LWJGL, i learn OpenGL, no ? Or LWJGL changes in the concept and makes some differences between the native OpenGL and itself ?

Because I really want to learn OpenGL, and Java is the only langage (for application of course, because i’m quiet experienced in web-based developement) which i know for the moment. So i want to learn an API which is the nearest as possible of the OpenGL which you can see in C tutorials…

But if the both APIs haven’t so many differences, i can make a very light layer abstraction, to allow the user to choose between the two bindings of opengl.

LWJGL supports GLSL (woo, acronyms ahoy!). Theres a small tutorial-y thing on the LWJGL documentation wiki (under shared code) with some handy code chunks for loading/compiling/etc.

LWJGL is pretty much direct OpenGL, in fact its closer than Jogl so its easier to convert existing tutorials etc. (particularly the display creation stuff which is needlessly complex and fragile in Jogl).