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.
I've seen this story of before
Get your Unix fortune now!
As a professional Java developer, an avid gamer, and a hobbyist game developer, I can tell you that there is no way this is going to work for certian types of games. Quake [X] will never be written in Java.
However, many types of games (RTS, for example) almost beg to be written in Java for two reasons:
1) They need good game logic (and design) and not high framerates in order to be sucessful. Java fosters good design and is less prone to errors (buffer overflow anyone?) while still allowing for acceptable graphics performance.
2) Because of a Java app's inherient portability, games can be written for smaller segments of the market that couldn't be written before because the limited market, limited even further by a specific platform, did not warrant the cost of development (and porting to other platforms).
Why bother? Because things change. Years after the 'most stable Windows ever' (Win 3.1) was introduced, gamers knew that the best gaming environment, without question, was DOS.
Now, it's Windows.
Next, why could it not be Java? They have as good a chance as anyone else. And, if the entire effort required to port it to a new system is to carry the CD over to the other box, game developers will be able to get access to a much bigger market with ZERO extra effort.
That is why they would bother.
Ho! Haha! Guard! Turn! Parry! Dodge! Spin! Ha! Thrust!
Let's thing about this for a moment... excluding fps titles... what games actually use 100% of the hardware they are running on?
Certainly not all. Games like Escape Velocy Nova that are Very popular (and only available on the Mac) would work great even with the elegid java performance hit.
Sure, Sun has a lot of work to do before this is a working solution... but you are fooling yourself if you think it can't be done.
--T
http://www.theMediaBunker.com
>So the idea of write once, run everywhere, of course requires that a set of gfx libs are implemented on every platform.
Once upon a time, there was such a lib - OpenGL (and its free version, Mesa). However to counter this, a company (whose name you know) introduced a proprietary, platform-specfic graphics lib. It started off lame, and is now supposedly pretty decent. (This is how this company generally performs).
Anyway, such options exist, but mindshare has gone away from them, in favor of convenience - who needs cross-platform apps on the desktop, when there is only one desktop of consequence, anyway?
ZOMG I WOULD LOVE TO KNOW ABOUT YOUR FEELINGS ON MACINTOSH VERSUS WINDOWS, VI VERSUS EMACS, AND HOW YOU'RE NOT A DORK
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.
Now i like java its a very nice language (although i havent really done much with it yet).
I still think its too slow. ive tried 1.2.x, 1.3.1 and 1.4 and i havent really noticed any performance improvements. - yes i can run any java program fine on my duron 900 at home with 512Megs ram but on my P 233 / 64MB laptop everything is dog slow.. even just javac Vehicles.java && java Vehicles takes at least 1 minute to spurt out text (in the console) about how many wheels each vehicle has.
and trying to run something like jedit (this is a really nice program btw) is painful!
now is there something wrong with my setup?
because if not i dont see java as a viable language for writing games.(except maybe something like xscavenger).
when everything is working perfectly.. BREAK SOMETHING before something else FUCKS up!
In 1977, many people were astounded by the first console video games and arcade games--devices unimaginable by the scientists, much less entertainment industry because the technology at the time was rudimentary for such devices.
But the popularity helped to fund the technology improvements and the gaming industry took legs.
Now, we play games with millons of colors in 3D spaces with near-virtual reality situations. It only took the maturity of the technology to make it possible.
Would Java game playing require a new technological paradigm to work? Sure--it can't work under the current model. When games first appeared in the 70s on TV, there was NO significant competiton. Today, the competition is too fierce for a new idea to compete directly and the performance of current games easily exceed what platform-agnostic programming might offer right now.
But then, Atari's games started with a handful of very large pixels and simple game premise. Nobody thought a video game would point the way to what has become.
For Java to work, it would need to take on a new competitive edge. I would suggest taking the open-source approach to the commercial side. Make a MAME-like, open source game player (this may take care of the hooks needed for platform performance) that's freely distributable and extensible.
Next, sell games. Some may be free, others not. But ALL could be placed on any OS and platform desired that supports Java. You would think that we have the ability to improve Java through hardware (such as a PCI Java "processor" expansion, also available for all platforms) or even let processor evolution handle it.
I'm not a pro programmer, but Java's general specs could be made to work, if companies like Microsoft (who are so profit driven to stifle competition) don't intervene. It would have to take baby steps.
QuickTime, Apple's movie/multimedia technology, started with movies the size of a postage stamp and was the first viable movie technology for computers. Today, it allows you to watch "Star Wars" trailers (don't start with the "Pro" version stuff--that's just Apple being a business). What could the future hold tomorrow if the playing field stays fair, although not necessarily even?
Vos teneo officium eram periculosus ut vos recipero is.
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
From the original article...
It sounds like Sony (developer of the PS2) is interested after all. Perhaps it's for their games consoles, perhaps it's for their cell phones, perhaps it's all hype, but they do seem interested.
You mean like Java3D? Most of the time Java3D is a thin wrapper around OpenGL, but on systems with no OpenGL it can be implemented differently.
Admittedly, sound has a very poor record on Java, but there has been a recent addition of javax.sound to the standard API that I haven't looked into yet. Basically, with excellent 2D graphics support, 3D graphics support and sound support - what other media does a game use?
Disclaimer: I write business style apps and so I haven't looked into Java3D or Java's sound support much, but I also haven't heard massive criticisms from Java programmers about them either.
Wahhh it won't run Quake 47!
Wahhh it won't go 950 frames/sec!
Wahhh it'll only work for puzzle games!
Wahhh too slow!
Wahhh graphics!
Wahhh budgets!
Wahhh what's the point?
Guess what, folks: games must break out of the upgrades per second rut or they will never be economically viable. There are perhaps 10 projects per year that are good investments. The rest are "throw all the money in the air and hope we can catch most of it before it blows away." Those are the facts.
The retail box model is horribly broken and will likely never be fixed. Game budgets must be reduced, or the game industry *will* become Hollywood, and in 10 years, choice will have been crushed and there will be three companies at most making clones and sequels that everyone must gladly line up and pay $199 each for. (heh, for that matter, what's the game industry doing these days?)
These kinds of technologies are a step in a better direction where *gasp* we might actually make games for someone other than the couple million people who play fps games all day. That's why it is important. A Java game platform does not seek to solve the problem of faster frame rates, or more polygons, because THAT HAS NOTHING TO DO WITH MAKING A BETTER GAME. The sooner the game industry gets past this myopic "cram another vertex" mindset, the better.
You're a schmuck. Assembler IS machine code. There is *no* difference, other than one is written as binary, the other as text.
The guy was clearly pointing out the falacies told in the past. Actually the average code turned out by a good C++ compiler these days is better than that turned out by good assembler hackers for all but a handful of very compact problems - crypto algorithms and graphcs being the principle ones.
The problem with the 'they laughed at Gallileo' approach is that although Java is eventually going to catch up with C in performance it won't be on the basis of the JVM approach. The problem with the JVM is that you don't have enough information to do really good optimization and generating that information is not the kind of thing you want to do just in time.
When it comes to cross platform gaming JVM is not a credible platform and no amount of Sun hype will make it so. .NET on the other hand does provide the optimization hints needed to do a good code generation phase.
Sun is really playing into Microsoft's hands here, this is one ground where performance is the absolute.
From a technical point of view Suns approach makes no sense for games consoles because the whole point of a console is that there is no O/S layer. That is how a machine with pretty tepid hardware performance can outpace a high end PC, there are no abstraction layers between the program and the hardware. It is like writing code for an early micro-computer, no O/S between you and the hardware.
More generally Sun's approach s clueless because they appear to not understand the way the gaming market works. The manufacturers deliberately introduce incompatibilities between players in different markets. Game console games are typically $15 to $20 more expensive than equivalent titles because the console companies charge for access to their platform. Sony and Sega don't want you to be able to play cross platform games and they will fix the hardware to stop you.
Xbox is kinda odd in that early reports stated that the hardware was open and there were no fees. Microsoft's interests are to have as many games on their platform as possible. But I doubt they would provide Sun with any help for their current scheme.
That leaves the PC platform running either Windows or Linux. There is absolutely no need for a virtual machine translation layer when the only platforms are i86.
While Sun goes on about the evils of Microsoft the only party that would benefit from this scheme would be Sun who would be able to market the SPARC as a games chip.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
It works on Linux, Sun, and Win32, and it hauls ass to boot! Quake3 in Java? It's definitely possible!.
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
...even just javac Vehicles.java && java Vehicles takes at least 1 minute...
The reason this is slow is not because Java is slow while it is running, but because there is a fairly heavy overhead associated with starting up the JVM. This is actually happening twice here; running javac actually requires the JVM to run. Once running, compiled java code runs at a speed in about the same ballpark as C or C++.
Where java is dog-slow, however, is in its GUI libraries, especially Swing. I haven't had a chance to try this yet, but supposedly there were some improvements in Sun's recent 1.4 release. Other GUI libraries such as the one from IBM whose name just escaped me also are supposed to address these issues.
Btw, anybody doing lots of compiles of java code and consistently swearing at the slowness of javac should try jikes. It's an open-source java compiler that runs as a native binary. Much faster than javac!
It's only software!
Java3D is not a wrapper for "OpenGL". It is often implemented as a thin wrapper for OpenGL calls, but is itself a standard which does differ from OpenGL (most importantly that it is Java based, not C based).
This library is probably written in C.
Correct, most java implementations are written in C or C++, the question is not that Java should always be used in place of C/C++, but rather whether you should take advantage of the C/C++ code already written by using Java and thus gain the cross-platform benefits of Java.
Just as OpenGL is a standard, so is Java (proprietary/non-proprietary is not the issue here). The Java standard includes not only 3D graphics abilities, but also sound, 2D graphics and in fact everything you need to implement a game and provides cross-platform compatibility.
As far as speed is concerned there have been and continue to be great progresses made in JITC compilation which is making Java quite comparable to C/C++. You should note however that speed critical sections of code are written in assembly, not C/C++ and this capability is still avaialable in Java (obviously limiting cross-platform abilities, but at least only the speed critical sections need to be ported).
It is easy to give the kneejerk reaction that Java is slower or that you can do it in C anyway, but the fact remains that Java is fast enough for a very significant percentage of games produced and provides cross-platform deployment much easier than C/C++. The advantages of Java are numerous, so the question shouldn't be why bother, but why not?
Do you guys remember when windows 95 was first released? Well, game developers shuned it despite microsoft's promise of some library called DirectX. Game developers and end-users had trouble coping with the percieved performance hit that games would take when written on top of windows (who needs another layre of abstraction when you are writing for performance). Well, DirectX and OpenGL on the windows platformhave since matured and almost all games are developed exclusively for windows. And i'm sure you all can see the parallels to todays talk of java gaming.
-adma
my other penis is a vagina
Hmmm... when you say C++, are you referring strictly to the object oriented portions of it (e.g., classes and such), or are you also including the standard containers (e.g., ANSI C++ strings, lists, vectors, maps, etc.). I would think C would give you the kind of control and performance required (at the sacrifice of portability, but if so many major open source apps can compile under Win32 and *nix and be written in C, anything is possible.) C code, encapsulated in C++ classes will give you the benefits of OOP with little gain in overhead. But I think if you were to use the C++ containers and other built in objects and methods, you might take a significant performance hit, even if these tools are optimized in your development environment (e.g., Visual C++ has some super-fast way of implemeenting the string class). I'm not sure if C++, using all of this, is really a fast language.
Of course, it would be faster than Java, but it may not be the fastest, most portable, option out there.
While we are on this subtopic, for anyone using MSVC++ 6.0, can you get <list>s to work? Every time I've used them, I've gotten programs which refuse to run correctly. Of course, g++ does not have such a problem LOL.
In case of fire, do not use elevator. Use water!
Two consecutive Slashdot stories:
-- Platform Independent Gaming?
-- Ask Slashdot: Most Outrageous Vendor Lie Ever Told?
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Java will never EVER be faster than assembly.
Thats probably because people don't have time to implement a lot of features when coding asm, not because ASM is faster. If you don't really know what you're doing, ASM code will be a lot slower then stuff spit out by a modern C++ compiler or JVM.
autopr0n is like, down and stuff.
a virtual machine can't be as fast as native code, but they're definitely getting close
Bzzzzt....incorrect. Read up on Hotspot. A VM can certainly be faster than native code, particularly in long running iteration-intensive situations. Can anyone say game engine?
All in all an interesting idea, the problem Java will have is getting the stuff to the screen - but there are decent gfx libs coming along. Can't wait
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
IndirectX?