hello 
how about performance of LWJGL and JOGL comparing to using OpenGl libraries in c++ ? (how much slower is java open GL )
Open ended question guaranteed to turn into a flame war.
Here’s one comparison:
Our pure Java VRML/X3D browser using the Java3D renderer runs the same speed as the other browsers written in C/C++ and using OpenGL or DX as the rendering API. Our OpenGL rendering layer, using JOGL is about 10% faster than either (we’ve seen 100% on some content), and that is without state sorting currently. That is measured on pure frame rates alone, and non-equivalent code architectures.
ie, it doesn’t matter what language or graphics API you use. Just design and implement your code well on the platform that is most comfortable for you to develop in.
Oh, I don’t think it’s likely to turn flamey. We’re all pretty much in agreement about the performance characteristics, that in a real world situation you will typically achieve between 80-100% of C++ performance in Java depending on the VM you use and the sorts of things you’re rendering and on what card.
Cas
I have made some adjustments to my jogl game (see post http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=jogl;action=display;num=1079942658 ). Now my jogl port is faster that the original c++ app ;D.
ok , so i’m almost convinced. But how about extensivity ? same code (yes , not same but same-making) in c++ and java , how much in memory? Lets say i would like to write quite complex game using shaders, bump mapping etc , is it possible to do it without getting out of memory error (while having heap on 512 ram f.ex ) ??
IME Java will typically use about 2x as much physical RAM to achieve the same task as a nontrivial C++ program (for trivial programs Java uses vastly more RAM because there’s a 11MB (?) VM footprint even on Hello World). It sounds pretty bad but this is the tradeoff for having it safe, secure, diagnosable, and bug-free, and with RAM being so fantastically plentiful it hardly matters.
RAM usage in a Java game is spread out in the following areas:
VM footprint
Bytecode & reflection data
Compiled code
Extra native DLLs & drivers (eg OpenGL)
Object header overhead
Objects themselves
Native bytebuffers for IO with native libs
Graphics & sound
The bits you don’t have in a C++ program are
VM footprint
Bytecode & reflection data
Object header overhead
You can do very little about VM footprint and bytecode but you can be careful about how many objects you create (for example, flattening an array of Vector3fs into a single ArrayOfVector3f with 3 arrays of floats in).
Cas
In a complex game geometry (with vbo), shaders, textures and stuff, have nothing to do with whatever overhead Java has as a platform. They’re all going to the graphics card/agp memory anyway.
Other than these, given today’s plenty of ram, a complex game written in Java is perfectly feasible and realistic. Oh, and more fun too 