I read this topic and I found it very interesting to see the advantages of Java weighed up against C++, so I thought I’d help you out.
I googled: “Java+Advantages” games; and this is what I came up with.
http://margrabe.com/JavaDP.html
Good Luck with the convincing 
Hauk
I used Eclipse on 450 MHz with 220MB RAM. It runed reasonably. I however liked more jEdit with some pluggins, because I dislike to leave source files handling to an IDE. One click could delete all your source files, and using HD recovery programs is a lenthfull problematic proces.
I believe Eclipse has some options that alows disable automatic reparsiong of the current source file.
Re cas
Everything not writen in the Assembly takes more memory and time to run than it should.
(In fact sometimes even writing program in C++ takes more time than writing it in the Assembly. )
[quote]I used Eclipse on 450 MHz with 220MB RAM. It runed reasonably. I however liked more jEdit with some pluggins, because I dislike to leave source files handling to an IDE. One click could delete all your source files, and using HD recovery programs is a lenthfull problematic proces.
[/quote]
Which is why we have subversion.
Will.
I noticed that most people have been responding to this thread from a developer’s perspective. And maybe that was the intention of the author of this thread. But you have to think about the game player and what a language can give to him/her.
Cinematic effects, high performance and response time.
I’m into AI. I’m at the start of designing an AI engine that will be complex to say the least. Is it very useful for game animation? I don’t know yet. But I do know that I need with this novel design I’m playing with, complex calculations being perform every second requiring lots of multithreading. I have been programming for quite some time. I’m just new to game development.
If you want real time rendering of photorealistic images, real time complex collision detection and real time performance, which seem like what the game writers are persuing, then you have to have a language/OS/hardware that can give it to you.
IMHO.
General comment:
In regard to rendering a good portion of us here use OpenGL via LWJGL or JOGL which is offloading this aspect to preferably recent hardware via the native OpenGL library. Since the 1.4 JDK JNI has definitely improved.
My developent:
In regard to collision detection… Well I have found that standard BSP collision detection works great in Java with the Auriga3D engine (Q3 based) that I will be releasing for preview soon.
Dynamics is another story… I will soon be looking into using the ODEJava project / ODE engine to provide dynamics with collision handled on the Java side. This integrating of the BSP collision system Java side with dynamics handled with ODE will be tricky and is theory at this point.
Audio:
I am using a state of the art audio engine called SuperCollider3. It is a C based audio engine, but it is also a network server and accepts a network protocol called OSC (Open Sound Control). Java is a wonderful language for sending OSC to this audio engine and controlling it locally or across a network. Either way it executes in a separate thread. NIO plays a big part here in efficiency on the Java side.
Your development:
I’d like to hear more on the AI engine you mention you are building. So far I have looked into Simbionic which has a Java port of the engine.
Conceivably you could build your AI engine in C/C++ and provide an accessible Java API if you find out that implementation in Java is prohibitive. Though it may not be… It depends on what you are doing. A fuzzy FSM based AI system should be able to be optimized for Java.
I dunno I am just throwing out my viewpoint given your comment… Of course as you see in three areas crucial to systems in game development I am looking at C/C++ oriented engines to handle the work. These parts are OpenGL/hardware accel rendering , ODE/dynamics, and SuperCollider3/audio.
Java is great as a bridge to DSLs (Domain Specific Languages or engines) that may be implemented in other languages.
Java can facilitate an easy to extend component oriented control environment that essentially forms a flexible glue between all of these areas. Given that the DSLs/engines implemented in other languages are cross platform (OpenGL, ODE, SC3 are) provides a nice pairing with a Java control environment as it should be cross platform as well.
Perhaps in closing these comments I will mention that right now something that is holding me up in my development activities has nothing to do with Java at all. At this point in time I believe I will be able to greatly extend the rendering options of my current work once the Render to Target OpenGL extension is approved and implemented by ATI/NVidia and other IHV vendors.
http://www.opengl.org/resources/features/GL_EXT_render_target.txt
I dunno… I am firmly convinced that Java has a part in modern development of advanced applications. Many of us here are forging the way…
Catharsis,
The AI engine I’m working on is still in the design and analysis stage. All I have is a first draft of an UML design and some test code written in C++. I’m a little reluctant to discuss it because I don’t know if it will work and I would like to save myself the embarrassment. As I stated before, I’m new to game development. But the thing I’m going for here is adaptive control.
Adaptive control is when a device or in our case a game character changes its behavior in response to a change in the environment.
Let’s take for example a space battle that requires many space vehicles to be in combat with each other. If the environment changes, for example the battle migrates into an asteroid belt, the vehicles will have to adapt to the new environment. (Recognize that an asteroid is not an enemy space vehicle, but it has to be able to navigate around it.)
I don’t really think this has been accomplished yet in a game environment. It may have.
But once I get to a point where I feel like this is acheivable I will be willing to show you or point you to a website that will show the progress of this project.
To make this post somewhat appropriate to this thread, I wonder if I could develop such a sophisticated design using Java. I like the language very much and have been asking questions (in another forum) about Java and 3D. There are games perfect for Java. But games that require lots of mathematically calculations done by the CPU as well as the GPU … I wonder?
I appreciate your inquiry. Wish me luck!
jfelrod - I’m not sure quite what kind of AI you’re talking about but Java should in fact be very well suited. AI is usually less number crunching and more object manipulation and method calling. Most AI used to be implemented in LISP to take advantage of lambdas and closures - these map onto classes (particularly anonymous instances) in Java. A while back I tried some unification algorithms in Java (core of a lot of deductive reasoning) and found them significantly faster than the equivalent C. Main reason being (I suppose) that Java doesn’t really use a stack - it’s all already on the heap - and Java’s method dispatch is well optimised while the C equivalent used a handrolled scheme that wasn’t as good. There are also very good and very fast implementations of Rete-style forward reasoning in Java.
Dave
[quote]A while back I tried some unification algorithms in Java (core of a lot of deductive reasoning) and found them significantly faster than the equivalent C. Main reason being (I suppose) that Java doesn’t really use a stack - it’s all already on the heap
[/quote]
Interestingly, you take us back on-topic. I’ve had C++ devs complaining that “java must be slow because it does everything on the stack”. I’m mildly embarassed to admit that it’s been so long since I cared that I can’t remember how much java does on one and how much on the other; I know I can still hand-code assembler routines to set up efficient stack frames for fn calls, and other pointless/useless bits of related knowledge, but the important bits have rusted away :(.
Ok this is my first post.
I’m old salt. Once my friends called me Bjarny because of my in-depth knowledge of C/C++. But I pretty much do everything in Java these days. And the everything is high performance computing - in java.
My .02 on the performance argument. For pure number crunching, a native compiled language will always win. It doesn’t matter how good the optimizer is, because the best optimizer is the developer, and if you hand code optimized stuff in C/C++, it will always out perform Java. And you can code directly to your hardware too…
Flames on! But a game isn’t all about blitting as fast as you can, right? All the optimizations that are often forgotten from the C/C++ world can be applied in the Java world. And writing slick Java code makes up for stupid performance issues when you take into account that anyone doing C/C++ development usually has to hunt around for all sorts of libraries or make them themselves to do UI, network, and the like. Java toolkits give you all this out-of-the-box, so you don’t need to develop it yourself, and for the most part its all x-platform. Tieing stuff to specific hardware means someone somewhere won’t be able to play your game. (HalfLife2 won’t run on my 100% Dx9 savvy portable /w integrated video.)
I have always had issue with finding good socket libraries in C/C++. I was so happy with Java, that I use it for all networking and db work. And this area is a place where it doesn’t matter if it is coded in C/C++ because you are typically bound by your connection speed and putting together your own brilliant adaptive gaming protocol.
Writing core games often meant writing your own memory managers and crap. This ground level structural work is a waste of time. The argument that Java bleeds objects and your game stops when the GC goes is bunk - because it means the developer architected/implemented it wrong.
So, the real advantages, IMHO
One cool thing if you aren’t writing network games portability to J2ME (that’s right, it runs on your cell phone too).
And then there are the caveats about Java… that will come up.
Well, that’s almost the opposite of the truth, assuming you mean “will always win against java” because a dynamically (re-)compiled language is always, in theory going to be at least as fast and often faster than a one-time compiled one, assuming complete optimization of both.
On a practical level there’s really no difference in raw number crunching since the executed code is practically identical, assuming no compiler bugs or quirks, assuming that your JVM is correctly written, etc.
So…what, exactly, do you really mean here?
Maybe you’re thinking of specific cases, e.g. new instruction codes? Historically, it’s taken Sun on the order of years to capitalise on new instruction codes (c.f. how long it took to get automatic SIMD, and even now it’s limited applicability. Ditto (on both counts) the OGL acceleration for 2D. Etc etc) That’s not number crunching, that’s a problem with the compiler authors (Sun) investing insufficient money. IMHO this is is foolish given the value of Java to Sun - I really struggle to see why Java gets such a bum wrap from the company. If Sony’s execs had been as conservative as Sun’s we’d probably still be on PS one, with “rumours” of a new version to come sometime in 2005…instead, they realised that PS == Sony’s future.
Actually, no, I don’t mean that. Local (loop) optimizing and code caching like hotspot are great, but they can get confused.
Take the following example.
I’m doing a FFT on a matrix of complex numbers to do some funky image processing.
First problem, complex numbers are most intuitively interpretted by objects in Java, and so every access of a field means overhead of 2 to 3 indirect reads. We are always virtual - so we have a churn of both objects and reads. For O(N^2 or N^3) operations on such matricies, the computational cost adds up.
And here is the other difference. Implementing this as a class in C++ you can take advantage of operator overloading as opposed to chaining methods to add/multiply. The generated code typically has a lot less in working code.
So, what I generally do, is rely on JNI and reduce my overhead my dumping the packaging and moving everything into arrays where I can use index magic and atomic types and/or hardware acceleration that works on atomic vectors where possible.
Problem again, is moving this back into Java, the repackaging and other (though minute) overhead of JNI. (Remember the argument of the defunt Microsoft RNI vs JNI.)
You can refactor/rearchitect your Java code to be more friendly at the expensive of intuitive behavior.
For gaming, most of the time, you can avoid any of the nastiness associated with using transcendental functions or complex numbers and the like… but not many people remember the old days/ways of approximating FP math with precalculated integer math.
I strongly disagree with the tendency to say “lets have an object for every complex number”. There’s little or no rationale behind it, other than people think it’s what they’re supposed to do. Objects are not something to make just because you had a Noun. So…I think you’re going out on a limb with your assertion here.
So, you’re saying that because in your example the author choose to do a stupid algorithm design java is therefore bad at number-crunching? That doesn’t follow.
You’ve lost me completely. Whenever I’ve used operator overloading it was a sugar for method calls - what is the difference?
Going by these forums, it’s more often a problem convincing people NOT to use lookup tables. Personal experience of current and ex-colleagues follows similar lines. Lookup tables can even be slower than just using the correct methods, thanks to JVM optimizations.
Structs! Structs! Structs!
Cas
[quote]I’m doing a FFT on a matrix of complex numbers to do some funky image processing.
First problem, complex numbers are most intuitively interpretted by objects in Java, and so every access of a field means overhead of 2 to 3 indirect reads.
[/quote]
Most performance critical computation with complex numbers involves aggregates of complex numbers (array, matrices, etc). It is natural to have objects representing these aggregates, but the implementation of these aggregates will usually use float or double arrays rather than arrays of some Complex class. When done properly you find Java gives performance similar to C/C++.
While it would be nice to have an efficient Complex class, it isn’t necessary to obtain good performance.
Good or optimal performance… I can do anything with good performance based on right algorithm, data structure, and hand coded optimization.
The reality of it though is the same strategies in compiled C/C++ outperform what I’ve done in Java, and I know this from experience and metrics I’ve gathered.
Its unfortunate that blah discounts everything I say as opposed to disproving it. All I can add is that conversations like this aren’t productive… buddy, write a gaussian blur in java and the same thing in C/C++. Do it on a 1024/768 32 bit image as many times as you can over 1000 iterations. The throughput will be at least 3 times more on the C/C++ side than in Java for the same implementation.
I’ve written my own complex libraries, linear libraries, optimization libraries, in C/C++ and Java. I’ve optimized code for a healthy portion of my coding life (20 years). I guess this means I know absolutely nothing.
That implies you do the same thing in java as in C++ and expect it to work as well, which clearly is not the case. I’m getting the impression that you tend to expect java to execute c++ code with no more alteration thatn changing the syntax. Different languages, different architecutres, require different approaches; given the topic, I assume everyone has that in mind already.
Otherwise C programmers would be insisting on writing single-class java applications with no objects and complaining that the java doesn’t shine compared to the C.
Not at all. Look back at your posts and mine. You have made some silly claims, including one that flies in the fact of simple logic, and one that is based upon the assumption that the code-writer uses a naive or just plain foolish implementation technique that in fact java developers don’t generally use.
You made a reference to operator overloading as being somehow more efficient, but you didn’t explain, and when I queried this you said nothing.
It’s hardly a case of me shouting down everything you say, is it? Until this post I wasn’t even aware I was arguing with you, I just thought I was pointing out some statements that - unless you decided to clarify them - were clearly mistaken.
[quote]I guess this means I know absolutely nothing.
[/quote]
Shrug. If you say so :P.
Others (including me) have done tests on a variety of code including FFT and found Java to give very similar results o C++ (Java has frequently been found to be faster in the case of the FFT).
If you are finding significant performance advantages for C++ over Java, then either there is some peculiar feature in the test (such as use of certain trig methods which are slow in Java because its accuracy specification is greater than that of C++), or there is probably something wrong with your coding.
NOTE: it is unreasonable to expect a good C++ implementation of a task to look very similar to a good Java implementation of the same task. Java’s superficial similarities are something of a trap. So while a simplistic translation is easy to do, when it comes to achieving best performance from Java, much C++ experience and habits are near worthless.
Most of the current perceived performance problems in Java stem from the fact that the only decent speed in Java is available in the server VM, and the server VM takes so long to get into its stride it’s basically 100% true that C/C++ is loads faster at doing smaller jobs. Until that two-phase compile stuff turns up, and maybe a bit of cacheing JIT code, C/C++ is pretty much always going to be a lot faster in this respect.
Case in point: JET compiled Alien Flux starts up in under 1 second. Server VM version takes maybe 30 seconds, client takes about 15. AOT compilation I’m afraid is just that much better right now until the VM engineers seriously address the issue.
Cas
With that, we’re going right back on topic, right to the core.
Speaking to C++ games studios, I’ve found a major issue I wasn’t previously aware of, that potentially ranks right up there beside “no playstation jvm”: fast deserialization of game-data (at least, according to them. But they don’t know java well enough and I don’t know C++ well enough ;)).
The method is that to load a 50MB level as lots of objects, polygons, and behaviours (event triggers) etc, at compile time you “bake” it into a serialized copy, and at runtime you deserialize the bytes straight into memory, with no time spent parsing or instantiating any data. I understand how this all works - with C it’s quite straightforward to be dumping data structures directly into RAM from disk, and then using pointer arithmetic to setup your function pointers to known offsets (i.e. it’s just that in C/C++ you have direct access to do your own runtime loader + linker, basically, within your program).
Now, although I’ve done loaders and linkers I’ve only done toy examples (loaded a single class worth etc) - never thought of manually doing an entire level like this. But this is apparently very common practice in games dev on consoles. And a lot of different games devs have thrown this up as something they’re seriously worried by the prospect of losing.
My initial reactions were:
Why are your levels replete with so many objects that parsing + instantiating them all from a non-baked level file is significantly time consuming? (the instantiation cost has been cited as the main issue, although I would have thought it would be the parsing that was more of an issue; perhaps by instantiation they’re mentally including the cost of hooking up all the internal pointers (which, I think, get baked-in - something you just can’t do with java; you’d have to manually iterate across the classes and set references)
How much time does it save anyway? (apparently an awful lot. Especially with poor console CPUs (c.f. consoles tend to have weak general CPU and instead lots of game-specific power)
How close could you get in performance by using structs and a memmapped ByteBuffer? (modulo the fact that memmapping is buggered in java 4 and I hate the possibility of having to do all games dev on java 5 :))
…how close without the memmaping (stream it instead) and without the structs (using the various hand-written simulations that several of us have done, which only differ in not being specially treated by the jvm)?
Presumably the reason AF starts so fast with JET is because similar baking is going on, so that in fact the game has been pre-instantiated at compile time, then serialized, and JET is deserializing and linking it?
Er, no The reason is because the JVM is slow. The JET VM has to do exactly the same operations as the JVM when it loads Flux - deserializing, etc. etc. It’s basically a brilliant, real-world benchmark illustrating the only difference between the two deployments: AOT compilation.
This is why I’m willing to bet that a JIT that caches its code into AOT will be a huge winner.
Cas