Slashdot Mirror
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.
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.
It's hard to be religious when certain people are never incinerated by bolts of lightning.
That is right.
And opposing to this proposal from SUN it already exists ! 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".
Hello?? Fred?! Is this you?
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.
dominionrd.blogspot.com - Restaurants on
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.
Space may be the final frontier, but it's made in a Hollywood basement. --Red Hot Chili Peppers, Californication
It works on Linux, Sun, and Win32, and it hauls ass to boot! Quake3 in Java? It's definitely possible!.
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.
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.
Duke Nukes Stuff. 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 for more info.
Javascript + Nintendo DSi = DSiCade
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.
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).
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
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.