

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.
More information here... (Score:3, Funny)
This can only work for some games (Score:5, Insightful)
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).
Re:This can only work for some games (Score:2)
Sure, it's easy enough to write Tetris in Java and make it platform independent, but how does that help the people hanging on to their Windows platform in order to use Unreal 7, Wolfenstein 6D, and Tribes 4?
Re:This can only work for some games (Score:2, Insightful)
Sure, it's easy enough to write Tetris in Java and make it platform independent, but how does that help the people hanging on to their Windows platform in order to use Unreal 7, Wolfenstein 6D, and Tribes 4?
As of last week, these are the top selling PC video games (according to ArsTechnica.com):
1) Command & Conquer Renegade
2) Medal of Honor: Allied Assault
3) The Sims: Hot Date
4) The Sims
5) RollerCoaster Tycoon
6) Harry Potter and the Sorcerer's Stone
7) Civilization III - Infogrames
8) Zoo Tycoon
9) Entertainment Multi Pack
10) The Sims: Livin' Large
I would bet at least half of these games could be written in Java and still have the same level of game performance. In addition, I would bet they would cost 20% less, take 20% less time, and not require any additional costs to port to other platforms (or additional distribution or maintainence costs for different versions).
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
Re:This can only work for some games (Score:2, Informative)
Re:This can only work for some games (Score:5, Insightful)
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).
Oh yeah, all very well if you're talking PCs. I'll wager that most 3D PC games could be written in Java and, although they'd suffer a bit of a hit in speed and memory requirements, at least the rendering would run fast, and they'd still be playable.
But this idiot is shooting his mouth off about consoles. Let me tell you, it's one thing to have a layer like OpenGL when all the video cards it needs to handle are basically the same. GeForce, Radeon, whatever, there's some differences when you look at the very newest features (e.g. pixel shaders) but for 99% of their functionality, it's the same.
Now compare this to the PS2, where instead of having some crappy "vertex shader" to do transformation & lighting, you effectively have a full featured CPU. How wasted is this going to be when your Java gaming platform can't ever call upon it to do more than the basic stuff supported by PC cards? It won't be rendering too many bézier patches with dynamic level of detail [gamasutra.com] with this Java platform, will it? Now take into account what whilst all the PC cards are competing over who can have the most texture stages handled in hardware, the PS2 resolutely sticks to one, and if you want more, you do multiple passes. Thus totally changing the approach you need for texture tricks like lightmaps, reflections, shadows, etc.
Nope, if you want a replacement for C++ as your language to call OpenGL or DirectX with, Java could fit the bill, but if you want to program a PS2 - forget it.
Re:This can only work for some games (Score:2, Insightful)
Lets not forget that most major game companies use cross-platform graphics libraries such as their own OpenGL implementations or commercial offerings like Renderware. Sony's PS2 dev team themselves has their PS2GL project to expose a clean interface to the PS2. And to take your example of the Bezier subdivision used by SSX, well that game has been successfully ported to both the X-Box and the Gamecube with added graphical effects.
Finally, it is rather unlikely will again choose such a radically different architecture without providing a clean graphics API along the lines of OpenGL for their next consoles. It took a full year for games that made full advantage of the PS2 to come out, by which time the next gen consoles from Nintendo and Microsoft were coming out! Sony made the developer's jobs harder than it should have been and paid the price by having a lackluster game offering for the longest time. Luckily, truly excellent games such as GTA3 allowed them to triumph over their competitors last Christmas.
Re:This can only work for some games (Score:2)
Except that you DON'T use C++ to program to the PS2's hardware. The Vector Unit's use macro (VU0) or micro assembly instructions that are preloaded into their instruction memory before running. Similarly, programming the DMAC controller relies upon building a DMA chain structure in memory and then triggering an upload.
Dude, I know, I program PS2's for a living. That was my part of my point - Java is a replacement for "C++ code used to called gfx library functions", not a replacement for what you need on a console (on a PS2 anyway).
What should happen is that the graphics library exposes a clean interface to the programmer, either C, C++ or Java and NOT assembly or hardware related.
Well, yes, if you value programmer ease over maximum performance. This generation of console wars will probably decide which way the console makers go in the future.
And to take your example of the Bezier subdivision used by SSX, well that game has been successfully ported to both the X-Box and the Gamecube with added graphical effects.
Oh, of course, I wasn't suggesting that what you could do with the VU1 code you couldn't do any other way. Just that you couldn't get PS2 _and_ Gamecube _and_ Xbox _and_ PC all running nicely with one codebase, whatever the talking heads at Sun might think..
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:This can only work for some games (Score:2)
Anyone serious about doing OpenGL (which is anyone serious about cross-platform 3D graphics) should visit NeHe Productions [gamedev.net]. They have examples for C, ASM, Java, C++, and even Python. They use a cross-platform NMI mapping that works on Unix, Windows, and Mac. You'll have to play with them to get them working though (classpath and security settings). Would be cool to set up a Java Webstart for them
Re:This can only work for some games (Score:4, Insightful)
Quake [X] will never be written in Java.
Never is a long time. You must have some special insight into the future to argue with such authority against Moore's law. Don't you think there was a day when they said that Quake could never be written in C?
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.
Now, I can believe that thinking... (Score:2)
Re:This can only work for some games (Score:5, Interesting)
Re:This can only work for some games (Score:2)
Re:This can only work for some games (Score:3, Insightful)
This historical retrospective was brought to you by sarcasm.
Re:This can only work for some games (Score:2)
A core design principal of Java is that the answer must be "no".
One of the issues in the Microsoft criminal case is that they are trying to make the answer "yes".
Microsoft licenced Java and made a commitment to support it. They then released an intentionally broken version. They then developed a competing eqivalant for DOT-NET. They then announced that they were killing Java support. I believe one of the results of the criminal case is that Microsoft will be *required* to provide Java support.
-
Pong (Score:2)
Really thou, how can you bang the hardware using java? Normally 3-4 years after the hardware is out, people start pushing the hardware to its extreme. Thats when the games truely shine. Will java be able to take in account all the extra features and use them? Then doesnt it break the "run anywhere" model?
Cool idea, I'd sure like to be playing Halo on my PC right about now.
This will never fly (Score:2, Insightful)
To be clearer, if you have system A, and have company B develop games only for your system, and those games are popular sequels or highly sought after, all the people can do is buy system A to play these games. By buying system A, more developers will want to license to develop games for your system, since that will probably mean a higher yield of sales.
Now, if suddenly people can play system A games on, say, systems D, G, L and P, then exclusive contracts are pretty much useless, and as such, there's no real push to buy any single system. Most people will go with the cheapest system.
I don't see how any of the game system manufacturers would approve of this.
Re:This will never fly (Score:3, Interesting)
From the original article...
It sounds like Sony (developer of the PS2) is interested after all. Perhaps it's for their games consoles [playstation.com], perhaps it's for their cell phones [sonyericsson.com], perhaps it's all hype, but they do seem interested.
This is not worth it (Score:2)
However, I don't think that Java makes sense for any *serious* (e.g. console/PC) gaming, you still need a healthy amount of native code to get anything done, right? So the idea of write once, run everywhere, of course requires that a set of gfx libs are implemented on every platform.
So fine, even if you do that, suddenly there's no real competitive advantage for the consoles. There are features you wouldn't be able to exploit on some consoles, you would have to cut corners. Ultimately you are limited, you can't push the envelope without writing native code for a specific platform. The gaming industry has progressed SO much because pushing the technology can produce better games. I want quality games. Portability of gaming code, in this industry, has to take a back seat.
Re:This is not worth it (Score:3, Insightful)
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?
Although they say multiple platforms... (Score:2, Insightful)
Read the article... (Score:4, Interesting)
Certainly not all. Games like Escape Velocy Nova [ambrosiasw.com] 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
Java's Crossplatform Shortcomings (Score:2, Insightful)
1) Performance - As others have already stated, Java is made for compatibility, not for speed. Most mid-range applications would start to drag down the machine, while hardware-specific code will enhance the speed and execution of the application. The games mentioned in the article are not hardware-intensive (You don't Know Jack, Who Wants To Be A Millionaire, Majestic), so they can transition to Java easily enough. For specific programming projects, such as graphically intensive games, many developers will probably stick to current standards or in-house programming languages.
2) Industry Support - XP's omission of a native Java RTE shows that not all developers are willing to go with Sun's development software. Additionally, many people buy consoles for specific software applications. If the need for a proprietary standard is removed, then people will go for whichever hardware setup is easiest to acquire. The game companies can't force people to get specific consoles to play games on. Yes, most of the video game consoles sell at near-cost (if not below), but many games are identified with a certain platform. Also recall a few years back, when Nintendo sued developer companies that didn't get its Seal of Approval.
Cross-platform programs would be appealing to consumers, but it will come down to if Java programming will find acceptance among other companies.
Believe it or not, Java is improving (Score:2)
Re:Believe it or not, Java is improving (Score:3, Interesting)
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
Get Real! (Score:2)
Do you honestly think that for really interesting games any virtual machine layer will not add so much overhead as to make the game unplayable? Sorta like Java Swing adds overhead to simple Windows apps...so you can get to see various Windows being repainted?
Most people do not like watching Windows repaint.
No offense to Sun...but the folks who are cutting edge on gaming will always write down to as specific as they can get to get as much performance as they can.
Besides....doesn't it seem odd that Id Software
has ALREDAY made it possible to play their games on any number of platforms...all by strictly coding in C.
But Id Software doen't make java, or workstations. They just make great games.
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.
Missing 2 things (Score:2)
The first is performance. Sun can take some steps to make this better, but games are about raw power. In order to do so, they'd have to really get their asses in gear. It might be easy to make the back-end deal with distributed processing and RMI and all that stuff, but the front end needs to haul ass.
The second problerm is MINDSHARE. In my experience, the vast majority of programmers (and probably games guys even more so) don't care about cross-platform, because THERE IS ONLY ONE DESKTOP PLATFORM. Some of them expressed interest in OSX (with Java, OpenGL, and all that) but really, they only see Windows + DirectX.
(Most of them don't even care about portables, phones, or Playstations for that matter)
Sun needs to overcome the midnshare thing, and get to work on the speed thing, before it even has a chance on the front end.
Won't be easy to catch on... (Score:2)
kick ass (Score:2)
Possible, If History Repeats (Score:5, Interesting)
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?
Re:Possible, If History Repeats (Score:2)
An academic argument. (Score:2, Insightful)
Why ?
Because no matter if SUN can make Java into a good game environment or not, the fact stands that the console manufacturers would never allow it.
Think about it - if a PS2 could run the exact same stuff as an XBox and vice-versa what distinguishes the two. It would only be a matter of time before SONY and Microsoft write a clause into their developer contracts...
x.y.z No Java Clause
You may not write your game in the Java language. Because it will eat into our marketability too much.
Consoles are a closed box system, the manufacturer of the console has complete control over what they will and will not allow with respect to what runs on thier console.
Can hear it already (Score:5, Insightful)
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.
Re:Can hear it already (Score:2)
The movie, music, and most of the gaming industries don't get it. They're just dinosaurs waiting for extinction. The only thread they have left to hang on to is the law. If they can't beat you, they'll sue you. If we don't speak up to our legislators, more draconian laws will be passed that will limit our freedoms and supply them a lifeline.
The Sonny Bono Copyright Term Extension Act [asu.edu] & DMCA [anti-dmca.org] need to be repealed; and the SSSCA [slashdot.org] (now CBDTPA [slashdot.org], or whatever it's called this week) needs to be killed before it makes it out of comittee.
Problem. (Score:2)
(Q is a GameCube clone by Panasonic that can play DVDs. It is unlikely, however, that it will ever be sold outside of Japan.)
What about Ultra HLE? Interesting implementation. (Score:2)
In other words, it was more of a translator than an emulator. Now that I think about it, isn't Wine like that?
Would this approach work with games? It seems like if this technique were ported to the PS2, GameCube, and XBOX, it would be possible to make portable games. Each one would have to be tweaked a bit on a per-platform basis, as each system has their strengths, but they probably could go a similar route that Ultra HLE did.
I have concerns about using Java for it. The problem is that the game hardware is a little too different. One technique that'd work on the XBOX would have a different effect on the GameCube, just because of how the graphics co-processors work. I think it'd be possible to make one game engine work on all machines to run the same code, but I don't think Java would be the solution. I think a cross-platform engine would be more suitable.
Re:What about Ultra HLE? Interesting implementatio (Score:2)
I imagine UltraHLE had to do some machine emulation, though, but maybe less than even an average SNES emulator would have to. Just enough to cover some of the games hitting the metal at times.
This will not likely happen. (Score:2)
Also, part of the reason that Java and C# have caught on as well as they have is because the PC is really quite stable in terms of basic functionality. Aiding this is the dominance of Windows. But the products that have really benefited from Java are not games. They are internet applications and productivity applications. Games are very dependent on exploiting the target hardware to the fullest. Also, that hardware is anything but uniform in its functionality. A Game Cube has no real resemblance to an XBox. A PS2 has no relation to any sort of other existing hardwrare. If a game was truly platform independent, it would look like a barely average game on the weakest of all of the platforms.
The only way this would succeed is if either Nintendo, Sony, or Microsoft become the ONLY player on the console business. And if that happens, there is then no longer any need for a platform independed game development language for Consoles.
END COMMUNICATION
Could this potentially kill the Game Industry? (Score:2)
What effect will this have on the game industry? Well, that's a little hard to predict. Here's a problem I face today. I bought a GameCube, I love it, but occasionally there's a game on the XBOX that I'd like to get. The problem is that the $300 I'd spend just to get the system is at least 6 games I could by on my GC or GBA. It would definitely be in my best interest for these games to be portable across the various systems.
Here's the problem, though. The dividing line that's preventing me from having too many games is the fact that I only have the GC and GBA. The different games coming out on the XBOX are so seperate for me that I'll continue to be a Nintendo customer. That is great for the companies that are focusing on Nintendo. But if I can suddenly play XBOX games on my GameCube, then it's just a flip of the coin which platform I want, and I'll be able to play all the games. Well, this leaves Microsoft or Sony with very little left to do except try to make new platforms for me to play on. The console market will suddenly turn into the PC Market.
The unfortunate problem here is that the PC Game Market isn't as lucrative as the Console market in some respects. The average shelf life of a game goes way down. A successful game is rated at like 500,000 copies sold, versus 2 million on the console platform.
Is there hope? Oh yeah. Eventually PC game makers will realize that a price drop would be in their best interests. If the average PC game were $35 instead of $50, people could splurge a little more. More copies would get sold. If the majority of the people who would have spent $50 on one game decided to spend $70 on two games, then the industry's audience widens, allowing more games to get made.
Personally, I think it is in everybody's best interests if the line between each console stays thick. Stick with a platform, cater to that platform, and then watch the money roll in. There's nothing more frustrating than having a game's quality diluted because it was transported to other different consoles.
Sure enough (Score:2)
Re:Sure enough (Score:2)
There has been a JavaOS. I remember downloading it years ago for the x86 platform. You had to boot into it from DOS. I can't remember whether it ran on top of dos or not, but the OS itself was very basic- think of a crappy desktop with a few token things like a calculator.
Basically it was just a shell for graphically launching java programs, which I thought was cool at the time because it meant you could run java progs without windows.
But then I tried to run java progs with it and changed my mind...
graspee
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.
Better idea (Score:2)
Check this out (Score:3, Informative)
This sounds familiar (Score:3, Interesting)
-adma
it defeats the purpose (Score:2, Insightful)
Amusing coincidence (Score:5, Funny)
-- Platform Independent Gaming?
-- Ask Slashdot: Most Outrageous Vendor Lie Ever Told?
Not that simple (Score:2)
Well, in order for this to be done there will be significant overhead -- almost to the level of emulator overhead. It will need to be sufficently smart also, for example you can't use any of the standard libraries like OpenGL or DirectX because some hardware may not support them and thus the application will break. This implies the creation of your own libraries which scale to specific hardware to use its features and capabilities.
Well, Java currently does not offer this. What it does offer is a good way to get really good simple apps running on a wide variety of hardware. However, games will always need 100% of what hardware can do to stay competitive, and by nature need hardware-level access. This means stuck to a specific platform, which is unfortunate.
If Java can provide really good hardware abstraction, with really good 3D graphics and sound libaries which are not dependant on 3rd parties, then there will still be a speed hit. Game developers need to attract people based on the latest technology. Being able to have products play in already niche markets doesn't interest too many.
I am sure such platforms as Linux don't even enter a game developer's mind -- they're too worried about what the competitor is doing on the graphics/game end.
An Easier Way to Make Games Cross-Platform (Score:2)
Wasn't too difficult either, mind you.
All you have to do is have different executables for each platform that all work off the same graphics, sound, level, etc. files. Given the current state of the gaming scene, it's most likely that the bulk of development is done on the accompanying graphics and audio files, complex game engines notwithstanding.
There ya go, no need for portability of code
How about some research before writing? (Score:2)
Would anyone else who actually WENT to the GDC like to comment? Here's what I saw at the Sun booth...
A Granbd Prix racer that looks as good as EA's latest , was cross paltform compatable with Win32, Linux and Solaris, and ran at better then 60fps on 1.4gig AMD witha GF3 GTS.
An FPS, equally portable, that ran at 145 FPS on the same kind of box.
A poster sized copy of the PC Gamer reveiw of Roboforge, a commerical game from Liquid Edge. PC Gamer gave it an "Excellent" rating (87%, which is very high in their scale.)
A 3D fighting game with real interactive shadows that ran at 60 fps on the 1.4Gig/GF3GTS box.
A MMOLRPG that looked terrific (better then EQ or DAOC, at least that's what pothers around me looking at it said) that apparently also runs on Win32, Linux and Soalris./ theyd eveloerps told us it took them a total of 2 hours fro mwhen theyw ere first handed a Soa\laris box til they had it running.
(See their GDC report at www.cosm-game.com)
An internet "Smash breothers" type game in 3D that looked and palyed terrific on both Win32 and a OSX Mac.
**sigh**
>>> flame on
Ya gotta love the internet. Its the only medoum I know of which so freely allwos thsoe who knwo nothing to inform those who knwo less. And slash tends to be the internet in microcosm.
Open your minds to new ideas and its amazing what "impossible" thinga you will discover are already happening.
flame off
And I suppose it will be named... (Score:3, Funny)
Re:Performance? (Score:2, Insightful)
OTOH the problem is that current console game systems are loss-leader items, meaning, that the company (sony, nintendo, MS) sell the console and take a loss. The game makers will then license games for the platform and that's where the maker generates profits to cover its initial loss.
A Java play-anywhere platform would provide the console makers no incentive to sell the consoles at a loss, since, any Java game could be played on any console, regardless of licensing. This will drive the costs of consoles up. Instead one of the big players (not Sun, but rather Sony, Nintendo, or MS) needs create an open platform standard and license the game makers to create games with this standard and license other console manufacturers to incorporate this standard on the console. Although the licensee console manufacturers will still have no loss-leader incentive, the original licensor console manufacture will still have a loss leader advantage.
I guess that my point is that Sun is the wrong company to be developing this, since they have 0% of any video game market.
Re:Performance? (Score:2)
Try these:
MagiCosm [magicosm.com]
RoboForge [roboforge.com]
Fullsail [fullsail.com]
The last use Java to teach their gaming students. There's a couple of kick-arse demos there that run just as good framerates and look just as good as any other commercial game. They have an FPS and an F1 game. Don't forget to have a look at the
Java Gaming [javagaming.org] website too.
Fast language like C++? (Score:2, Insightful)
Re:Fast language like C++? (Score:3, Interesting)
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).
Re:Fast language like C++? (Score:3)
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 [ibm.com]. It's an open-source java compiler that runs as a native binary. Much faster than javac!
Re:Fast language like C++? (Score:3, Interesting)
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.
Game Developers use assembly (Score:2)
Just because you can do 3d in java, doesnt mean its as fast as Assembly, we are talking consoles not PCs here.
Java will never EVER be faster than assembly.
Ok so you can make it fast, thats not the point, the point is if a game developer would use it
no. (Score:3, Insightful)
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.
Re:Why bother? (Score:5, Insightful)
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.
Re:Why bother? (Score:2)
I was referring to the gamers point of view. Windows has the best support for games, and you don't have to piss around with device drivers and himem settings to get them to work.
Windows runs games fast enough because of advances in hardware. When future advances mean that the performance of games written in Java is acceptable, other advantages of Java will become a factor.
Wrong (Score:2)
Console games? (Score:2)
Face it, Console developers write their own libraries, they have their own tools, and they write alot of the game in assembly.
Still using Dos? (Score:2)
Any help here?
Re:Still using Dos? (Score:2)
I haven't tried any DOS games on Win2k, so I can't help you there. Maybe you could just install some of your older games and see if they work. You also find lots of old DOS (and windows) games on abandonware web sites.
Re:Why bother? (Score:3, Insightful)
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.
Re:Why bother? (Score:3, Insightful)
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?
Re:Why bother? (Score:2)
next, on the java speed issue. you claim it to be fact that java is fast enough for a very significant percentage of games produced. the actual fact is that a very insignificantamount of games are actually produced by java. i'd say the game producers are most likely choosing the right tool for the right job here. after all, we all know that java development is much faster than C/C++ or assembly development, eh? A java game would be much more attractive to a game manufacturer, but which ones are doing it? I think a few may have behind closed doors, and the results were not plesant. When I see a java game produced which works as well or better than a C/C++ alternative, I'll believe that Java is fast enough for gaming. Nearly all java GUI applications (games are gui's no?) I have seen are useable but no where near their counterparts in terms of ease of use, and general responsiveness.
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.
AI ? (Score:2)
Its not the speed of the AI which would suffer, its the speed of the 3d graphics, java could never be better than assembly, its like tryingn to use visual basic to write a game, the problem with these languages, they just arent made for backend stuff.
Not console developers (Score:2)
Thats why console games keep looking better and better and PC games all have the same tired look
Re:Why bother? (Score:2)
Couldn't afford an assembler at the time, huh?
10 FOR I = 0 TO 19: READ A: POKE 16384 + I, A: NEXT I
20 CALL 16384
30 DATA 33, 0, 0, 17, 0, 1, 1, 0, 32, 233, 171, 201
That is Machine Code.
It is DIRECTLY EQUIVALENT AND IDENTICAL TO:
LD HL, 0
LD DE, 1
LD BC, 32
LDIR
RET
There is no difference between the two. Are you sure you're not mixing it up with microcode?
Re:Why bother? (Score:2)
A few 'C' statements will translate almost directly into ASM statements, but most translate into multiple machine language instructions. What machine language instructions are used depend on the compiler and you depend on your compiler to make good choices.
However, ALL assembly language instructions will translate directly into exactly one "machine language" instruction. That's why assembly language is essentially the same as machine language. You don't depend on anything but your good programming skill to choose which instructions to use.
Assembly language is machine language presented in human-readable form. No more, no less.
No sane person writes a program in machine language. They use assembly language which is slightly easier for the typical human being to remember than opcodes.
BUT, a program written directly as bits in machine language will be exactly the same as an equivalent program written in assembly language and assembled. That's why no-one writes programs in machine language because there's no benefit in doing so. You write in assembly language and produce code that is identical to the code you would have produced in machine language, but have only reduced your programming time by orders of magnitude.
Now, you can argue semantics, but the fact is that there is no practical difference in the results of a program written in machine language and one written in assembly language. Hell, you could argue that you can't even program directly in machine language because some intermediate program is going to have to convert your ASCII representation of the bits to the bits themselves.
Re:Why bother? (Score:5, Interesting)
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.
Re:Why bother? (Score:2)
Yet again though, the same issue comes up:
Why would you want to run
Now, admittedly,
.NET's VM is still non-deterministic. You can't force cleanup of objects, unless there's something I've missed. You also can't force objects to be allocated out of a memory pool. And it's tricks like this that people do to make games run smoothly and fast.
Simon
Re:Why bother? (Score:2)
Re:Why bother? (Score:2)
Re:Suffering at the hands of Compatibility (Score:2)
I'm sorry, but this isn't the 80's any more. Games haven't been written in ASM for years. Modern games are usually C/C++ with scripting layer on top. The cluelessness here on
Re:Suffering at the hands of Compatibility (Score:2)
graspee
Re:Suffering at the hands of Compatibility (Score:2)
That hasn't been the case since the machines were powerful enough to run a compiler and the choice wasn't assembly or Basic.
Interpreted languages have been used for games, still are in fact, but they are generally interpreters built specifically to do gaming. Infocom was the first to do this with an interpreter for adventure games which let them sell Zork for Apple and Pet (as Al Vezza pointed out to the designers they would have a bigger market for games on that machine than on the PDP 6).
Where are the facts? (Score:5, Informative)
The Difference btw game programming and a VM (Score:2)
Developing to processor architecture X allows you to-
Code in assembly when needed,
Hand-pick the instructions used to save cycles
Pick from more number formats, or hand-roll your own, result being its better for performance
Hand-optimize inner loops, data crunchers, and math routines
Mix assembler, C and C++, avoiding oop overhead as needed while retaining oop structure for high-level design
Choose your multitasking method, the OS, a thread package, or handroll your, the result being you can sync with the hardware
Oh yeah, you can sync to the hardware.. try that in Java
Developing Java allows you to-
Stick with the JVM's number formats and math package, although you can pull similar tricks (e.g. integer table-simu'd SIN(), but performs about the same as JVM's built-in SIN(), which is to say slow; same goes for ellipse and triangle drawing)
In my experience, using processor-dependent asm instructions allows number manipulation that can be several orders of magnitude better than Java's (which is rather dog-like to begin with.)
Use JNI to drop into C and assembler, but you need to manage platform-dependent packages more closely.
You can define your own number formats, but the performance loss is significant
Optimization can only be done in Java source
Threads are actually platform-specific in Java, for ex. blackdown port on Linux uses IIRC process-per-thread, (which is why LimeWire can be a real dog on excellent alternative to Java for cross-platform is WxWindows [wxwindows.org], and although its not optimized for gaming, it is pretty quick, in my experience its much faster than Swing for a window full of widgets.
Re:Where are the facts? (Score:4, Interesting)
Except that very few Java VMs emulate processors anymore. Most Java VMs these days are actually compilers in disguise. They simply take the Java byte code as input and compile it to native machine code then execute it. Due to the fact that it knows the exact details of the machine it will run on at compile time, it can actually produce faster machine code than C.
With the massive advances being made in JITC technologies and with hardware acceleration for Java (see Mac OS X), there is a lot of reason to think that Java can not only compete with C/C++ in the game market but actually beat it. Remember that critical sections of games are generally written in assembler, not C/C++ and this can still be done with Java.
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.
Re:Whoa whoa! Stop the "portability" train! (Score:2)
The point to all this is "easily portable". Let's make Sun & Co. do all the hard work of platform support. All people want to do is write a stupid game.
P.S. OpenBSD is cool, but I don't use it because it doesn't have Java
Re:Whoa whoa! Stop the "portability" train! (Score:2)
Re:Whoa whoa! Stop the "portability" train! (Score:2)
Stop this train already. It is a nice language, but I think Java "portability" is a big hoax.
Re:Whoa whoa! Stop the "portability" train! (Score:2, Insightful)
Presumably, what you MEANT to say, was
"... is well-written C, using a consistant, stable graphics API that is available on all platforms".
And even once that is satisfied, you STILL have to convince the software makers to RECOMPILE FOR YOUR PLATFORM.
You gonna go bug them all to recompile for OpenBSD? hahaha.
Whereas if it was java based, "all" you have to do is catch up to the other *BSDs, and get java working properly on your platform of choice.
The guy is a salesdroid (Score:2)
Go read the interview again, specifically the first paragraph. He *is* a marketroid, not a coder.
Re:The interview is absurd, but I'll bite (Score:2)
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:Java too slow! (Score:2)
There's a nice little article about 12 months ago from HP research department where they started putting native code into the same VM concept as Java uses and were getting 20-30% speed increase by interpreting the native code. Static optimisations are only useful in some cases. Dynamic optimisation that a VM can do as it analyses the code as it runs to optimise it for real world conditions give heaps of performance benefits. Guess what Java VMs have been doing for the past two years at least?
Re:Java too slow! (Score:2)
WTF? Java runs FASTER than native code? Where is this ? Inside a black hole ? In a dream ? On Gosling's whiteboard ?
I think you meant to say that it can run in some cases faster than the native code produced by a c compiler, though even this is going it a bit in the wishful-thinking department.
graspee
Re:Java is improving (Score:2)
Care to tell us how that is done? Java3D 1.3 beta only supports NIO for the geometry input through the data buffers, with no support for textures. Are you doing custom image loading and then putting the pixels in a VolatileImage to do that? Enquiring minds want to know if you are use Java3D or GL4Java, because it ain't in the spec for J3D.... Send me a private email on the link above if you want.
Re:ugh, yes, it will never play the newest games.. (Score:2)
Yes, computers will get faster, but it's all relative. By the time Java is fast enough to program games of type/graphics quality X then no-one will want to play them-
e.g. you say:
"In 10 years it will probably be easy to run RTCW on any machine,"
I don't want to play RTCW in 10 years, much as I don't want to play Wolf 3D today.
And, as many people have already pointed out, games with lesser graphics, such as the isometric 3D used for sim, strategy, turn-based battle etc. very often have extremely cpu-intensive game logic, which is precisely why they don't write them in full 3d...
The only game I can think of that does a lot of "thinking" and remain playable in 3d is Black and White.
graspee
Re:from the pigs-might-fly-department (Score:2)
Halo is supposed to be coming out for the PC. (Probably once MS are convinced that no-one else is going to buy an xbox because there's no other way to play Halo).
And hell, it's not *that* good anyway. Certainly not the "killer app" you have to buy the console just to play it... It does work better than any other fps I have seen on a console, and has good production values (polished, like Half-Life) but there better fps on pc.
graspee