Platform Independent Gaming? 505
klocwerk writes "At the game developers conference, Sun is releasing a white paper on their new "Java Games Profile." Their ultimate goal? To have one CD you could pop into an Xbox, a PS2, a Windows machine, or a Linux machine, and play the same game on them all. If they get full support for it I can finally get rid of that windows gaming partition!" Sun's got an article on their site describing what they hope to accomplish.
Where are the facts? (Score:5, Informative)
Re:Why bother? (Score:4, Informative)
When running a game, the main overhead isn't the speed at which the instructions are executed by the CPU, it's drawing the graphics. As long as Java can use hardware acceleration with the video card, the speed of the language hardly even matters. Anyway, JIT Java can get pretty fast if well compiled.
Re:They don't need to... (Score:2, Informative)
That is right.
And opposing to this proposal from SUN it already exists [amiga-anywhere.com] ! Full binary compatible video games, running on the AmigaDE (which is more of a "virtual computer" than a "virtual machine". Plans are to make this a stand-alone OS, binary independant, coming with complete HAL and a virtual CPU concept. (Similare to Transmetas "translation" layer between the CPU and the Software, but this is CPU independant and offers much more (API and driver wise)
"AmigaAnywhere" (aka: "AmigaDE") runs currently hosted on Linux, Windows and WindowsCE.NET utilizing many diffeent CPUs and hardware, such as desktops, PDA and cell-phones (did not see the latter but ithasbeen planned/announced).This is a product in its early stages however and one has to see where it goes. But it is not only a gaming-engine. It is to become a real, completely hardware independant "instant OS / instant computer".
Re:Get Real! (Score:3, Informative)
An example of why java guis dont need to be slow is eclipse. You can't tell its written in java (except maybe the slow load time :-)), but this uses a a different windowing toolkit.
In summary, the VM adds overhead, yes. But the VM is not the cause of a lousy GUI toolkit.
Re:This can only work for some games (Score:2, Informative)
Check This Out (Score:5, Informative)
It works on Linux, Sun, and Win32, and it hauls ass to boot! Quake3 in Java? It's definitely possible!.
Re:The interview is absurd, but I'll bite (Score:1, Informative)
Here's how this happens. The JIT, usually hotspot, organizes a table of functions and likely memory demands, and stripes this in memory to fit the cache size for the processor. This sort of information is not available in a static analysis (e.g., like with gpp, or even javac for that matter). Instead, it learns this by running the code. Then, the JIT arranges this so that cache lines are kept local during execution. The time to access a cache hit is about 3 ns; the time to flush a cache and fetch an instruction buffer is like 100ns, mor or less. (Yea, this varies alot, but it's like several orders of magnitude or at least one order of magnitude.)
So that's how Java can be faster than C++. The trick is, however, that the program has to be run long enough to create a learning curve. And there are some pathological programs that don't have a regular pattern of instruction and memory use. But most do have a pattern, and Java leverages that. C++ is limited to static analysis, which (because of the halting problem) can't predict with much accuracy what portions of a program will be associated with which portions of memory. (Plus, memory is dependent on what else is running when the program is loaded, etc., etc.)
Now, if you just took a simple program like sorting, well, hell, C++ blows Java away. But if you have a complex program that runs for a good while, then Java matches or even beats out C++ and even C. It's all about the cache.
Dynamically Recompiled Apps+VM *could* be fast (Score:2, Informative)
I'm not going to say that any particular JVM I've used has been amazingly fast (i.e., coming anywhere close to a C app), but the potential is there.
Garbage Collection can actually improve locality, and thus cache hit rate... which leads to faster performance. Years ago, in 6.001 (a introductory programming class), we all had to read about how generational GCs can result in a net speedup due to improved cache performance, *including* the cost of the GC itself. I'm not saying this is common, but it's possible.
Also, a dynamically recompiled machine can perform runtime optimizations that you just can't do at compile time.... finding hot traces and inlining them, for example. The Dynamo project dynamically recompiled PA-RISC into PA-RISC (yes, kind of strange) and got net speedups over -O4 executables in several cases. The same technology can be applied to Java.
Again, I'm not saying we're there yet, or that we'll ever get there with Java, but the nay-sayers should realize that a VM language system allows for all kinds of "magic" optimizations that CAN more than make up for the overhead of the VM itself.
Re:Where are the facts? (Score:5, Informative)
They can take into account the processor they target quite well - they just don't know exactly what their target is. What is the bus speed, how much ram, how many registers, is this a 386, a 486, a PIII, a PIV, an AMD, etc, etc. There are *huge* variations between computer configurations that can only be known at runtime. JITC can take this into account, C compilers cannot.
As for VM hardware, whatever.... My Athlon running x86 Code can beat any little dorky JIT compiled code.
The Athlon has more instructions than x86 code does - most of it added specifically to increase the speed of specific tasks and these enhancements are not always found in the Intel offerings. A JITC can take advantage of these things, C code has to be generic (or include special cases) as the runtime processor is unknown. So in fact, JITC code will quite often run faster - the biggest factor is how good the JITC is and when the JITC runs. Sun's Java implementation interprets the code at first and then compiles code which is used repeatedly in the program, though it is simple for the developer (or knowledgeable user) to change this behaviour.
Check this out (Score:3, Informative)
Re:This can only work for some games (Score:3, Informative)
As a professional Java developer, I've learned not to give up on Sun. Java's potential has jumped leaps and bounds in the last few years.
Gamecube can do things PS2 and Xbox can't, vice-v (Score:1, Informative)
Re:This can only work for some games (Score:2, Informative)
2) FPS - no other information
3) Simulation - could be
4) It's like #3 but without all the features - could be
5) Business Sim - *wets pants in anticipation*
6) Movie franchise - shit, if they can make a movie franchise game on 2600, they can do it in Java
7) Simulation - probably
8) Kiddie Simulation - probably
9) Multiple games - dunno
10) SWEET BLACK BABY JESUS WON'T THEY STOP MAKING THE SIMS EXPANSION PACKS - could be
Yes...Java CAN do it! (Score:2, Informative)
JVM's (Java Virtual Machines) ARE platform dependent. As such, they are tightly integrated with the host platform. If the hardware venders (i.e. Sony, Nintendo, Microsoft) create a JVM for their consoles, there would be no reason for poor performance. This, my friends, will be the ONLY way to create successful FPS games in Java.
Much like the OS for these games are highly optimized for the hardware platforms they run, so must the JVM's. Add JIT and there is little, if any, performance hits on the executing code. IBM has benchmarks showing the performance of their JVM;s ability to JIT effecent code.
As for Java's portability... Some dumb schmuck felt there was a need to proclaim that Java is not portable. I will agree, GUI code may not be 100% portable, but the server-side is damn near close...maybe 99.9% I have NEVER had ANY problems writing my Java code on my Win2K machine that was targeted for the Mainframe...or Oracle.
...and you have to be nuts to think the XBOX does NOT have an operating system!
This would introduce an IDEAL development environmnet for game developers. This would significantly increase ROI and market share. Not to mention the potential for newer/better game consoles.