I bumped into this stuff by acident today when i was looking for the x3d test suits:
http://www.openscenegraph.org/
It has bindings to java:
http://www.openscenegraph.org/osgwiki/pmwiki.php/Community/LanguageWrappers
I looks a good api with a solid design based on patterns. With the Java wrappers this stuff looks very usable to make some games. There are some games being made with it already. The screens look very nice:
http://www.openscenegraph.org/osgwiki/pmwiki.php/Screenshots/DIOSoftPirates
Interesting. But the pirates game is not written in Java, is it? Would be good to hear how well the Java wrapper is performing.
Its a comercial game i think. But whats the suprise of a game being written in java ? Vampire the Maskerade Redemption was written in Java and had only a small C++ core interfacing to SDL (not sure about the SDL part). If you don’t believe me check out Vampire directory and look for the Java Virtual Machine .dll and the classes.zip file.
Vampire just uses Java as a scripting engine I think.
Cas 
[quote]But whats the suprise of a game being written in java ?
[/quote]
I’m not suprised of a game being written in Java (although I’m not aware of any successful title outside the indie scene but still believe it will happen sooner or later), but I’m wondering if writing a game in Java that uses bindings to a C++ engine is feasible and worth the extra effort.
Short answer: no, not really.
Cas
It still have some doubts, however, that interfacing directly to opengl is a better solution than interfacing to a small core 3d engine. You may gain something by having a scene graph being processed in the C++ core than in Java.
I think the only way to know this is to make small game prototypes and then measure the two aproaches.
FYI, RedStorm used Java 1.1 as the basis for a few of their games. Thin JNI calls to a high performance GL/DirectX engine allowed them to get the rest done quickly in Java. I don’t know of all the games that use it, but I do know of a few for certain:
Tom Clancy’s: Politika
Shadow Watch
IL-2 Sturmovik
Tom Clancy’s Rainbow Six
This thread from last year has a few more.
[quote]It still have some doubts, however, that interfacing directly to opengl is a better solution than interfacing to a small core 3d engine. You may gain something by having a scene graph being processed in the C++ core than in Java.
[/quote]
I suspect that - ignoring explicit rolling and unrolling of data - the further you can go before traversing the JNI bridge, the fewer calls will be required. How much time this saves, however, is open to debate. (Probably not a lot.)
Unless you’re interfacing to a previously-existing framework that provides sufficent features to make it worthwhile, it’s hard to see what C++ will bring to the table. Are there any examples you could mention, actual or theoretical?
No. But with a game proptotype we could actualy benchmark the advantages of having a small core engine versus a direct binding.
Actually I think that’s exactly what you can’t do. Choose, stick to your guns, release.
Cas
I don’t get it. The only thing its necessary is to write two game prototypes. One uses a direct binding. The other is exactly the same game but working on top of a small core engine. You then run the two games in similar environments and benchmark the two.
Here’s how the game could be divided in layers for the prototype using a core engine:
(Java/C++) Plugin Layer
With a Java binding the only thing that changes is the bottom layers:
(Java/C++) Plugin Layer
The one thing you might be able to measure vaguely is “complexity”, and even that’s going to be vague. My gut feeling is that the bigger it gets, the easier it will be to have done it all in Java.
Performance measurements are meaningless for a prototype. Only the end result actually counts and you will never know until you’ve done it.
The concrete proof is that no-one is going to bother doing this prototype There are better things to do, like actually writing games!
Cas
Or use a currently available binding to the irrlicht engine or ogre/ode to test with…
I think it depends on how close the prototype is to the final product. After a certain point of game production (usually after the proof of concept) building the game resumes itself to adding more art and building more maps, which is mostly the job of the game designer and the artists.
So if you build a prototype that accurately matches parts of the game you are planning to do, its possible to actualy take useful benchmark info from it.
Less of a prototype really then tho isn’t? ;D More of an empty engine.
Kev
Prototypes in computer science are used a little differently than in other areas. Another way to look at is to consider an engine divided in parts (plugins). This way its possible to switch parts with similar interface but different internal design (jni access could be hidden in here) and test them in a controled environment similar to the one your game will run. Im not saying anything new here. This stuff is done in other areas (like digital components) for ages and even in some java apps i have seen.
Notice that some games like HL2 already suport something similar to this. You can switch the renderer in HL2 to any of DX7, DX8, DX9 shaders v1.0, DX9 better shaders. This happens without reseting the engine. The game recaches its textures and models at the moment without messing with the game status.
A similar thing could be done with Java with a choice of having a renderer that supports more stuff in an hidden native layer or a renderer that just uses binding facilities or even just a software renderer that would allow the game to run as an applet.
EXperienced developers know that there’s no such thing as a prototype. Once someone has your prototype in hand, they’ll just say “Oh, this is great! We can just use this!”
Anyone who’s believes their employers about it “just being a prototype” is either inexperienced or not very smart.
LOL! So very true.
Cas
Yes, and any further assertion on the part of the programmer that what has been produced is only a prototype usually - in my experience - provokes the response of “Oh, but we’ve already sold it…”
It’s either that or “I know this is a prototype, I know it needs to be re-written before anything else happens, but - just out of interest - what problems are we likely to run into if we deploy it anyway?”
Zingbat, have you thought about using Xith3D? That’s already nicely abstracted out into user, scenegraph, and render code. Why not write yourself a software renderer to test the Pure Java codepath, and reimplement the scenegraph packages in C++ to test the Native Scenegraph codepath?