Platform Independent Gaming?

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?

[JohnA]

but in all reality Java is barely cut out for hardcore applications that require intensive processing

Why do you say that? It's not as if most games are doing Fourier transforms in real time. The myth that Java is inherently slow because of the VM is false.

It is a great idea but it prevents the full potential of any individual console from being reached and of course without reaching a consoles true potential the games are going to be extremely limitied in their potential

If you follow this rationale, then DirectX for windows or OpenGL under Unix is also a limiting factor in game development because it has to support a variety of chipsets and rendering engines. History has shown that portability layers are a good thing in software development (NSPR, APR)... why not apply the same principles to game development?

Re:Why bother?

[damiam]

And, it has the added bonus of being written in a fast language like C++ and natively compiled.

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...

[amix]

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!

[LadyLucky]

Swing is a bad example. It runs slow even when compiled to native code (in fact, a bit slower). The problem isnt the java, the problem is the inherent design of swing in which you are very deep in inheritance trees, much abstraction going on.

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

[codingOgre]

I thought the same thing until I went to JavaOne last year. There were 2 guys, that worked for some game company, on the pavillion floor that inplemented a pretty cool FPS using the Java 3D APIs (These APIs use OpenGL for hardware accelerated rendering). They were getting 60fps running 1024x768@32. The PCs were pretty beefy and of course they were using Nvidia's latest cards, but pretty cool never the less (They were also using the 1.4 JDK for MMIO). It can be done, just wait for a couple more iterations of Moore's Law.

Check This Out

[Enonu]

This API absolutely rules: GL4Java [jausoft.com]

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

[Anonymous Coward]

I find it impossible to believe that a bytecode program, which runs on top of a VM (written, by the way, in C++ or in an equivalent imperative language) could be faster than C++ unless the programmer is absolutely clueless.

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

[edwinolson]

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?

[TheAJofOZ]

You don't think that native C compilers don't take into account the processor they target?

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

[AKAImBatman]

Duke Nukes Stuff [dnsalias.com]. Before the code was VSync locked (and timing locked) it ran 400 FPS! Say what you will, but Sun has come through this time. See Java Gaming [javagaming.org] for more info.

Re:This can only work for some games

[bay43270]

Take a look at JavaGaming.org. They have some screen shots there that might change your mind. Keep in mind, this stuff is pretty new. It's only getting better.

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

[dolphin558]

and vice versa. I'm not sure I would want to purchase these games because they couldn't utilize the advantages of each console. What if I like Gamecube because of the way it uses anti-aliasing? Well, the AA capabilities of the PS2 pale in comparison and a universal game would have to accomodate the PS2's weakness. I don't want a game in which I know could only be mediocre(especially if you a Xbox or Gamecube).

Re:This can only work for some games

[bonzoesc]

1) FPS - runs slow on my 1.2G Thunderbird - no
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!

[Anonymous Coward]

First, I would like to point out that many of the people posting seem to have no clue what they are talking about.

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.