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).
I bet pong looks great on each.
:)
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.
Because the developers of the systems are almost always losing money, or just barely making a profit, on the game systems. They make their money by the licensees developing games for their systems, and by having people want to buy their systems to get those games.
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.
Human nature is the same everywhere; the modes only are different. -- Earl of Chesterfield
I work in Java tooling.
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.
Well, actually Java is very similar to C++. If you study your Java history, the guy who thought up Java (I think his name is Gosling) was a C++ programmer that didn't like some of the things in C++, such as multiple inheritance. He rewrote some of the compiler rules that removed the things he didn't like and included some libraries of things he did like. Since then, Java has developed into it's own language. I program is C++ and I just learned Java, and I do most everything in Java now. You CAN do 3D in Java, and if you do a good job, it isn't slow. You can natively compile Java to only run on one processor, like C++, but that defeats the whole purpose. Compiling it to ByteCode and running on a JVM is the way to go. The latest JVMs are a lot faster than previous ones. If you haven't looked at Java in a while (and I don't mean the cheesy web applets) I suggest you take another look.
"Da ist ein Technölüst in mein Unterpanten!"
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!
ASM is king of the gaming domain, and I don't see that ever changing. /. is sometimes mindboggling, people seem to be making facts up as fast as they can write First Post!
J.
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
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
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.
This
As an example of a Java application (though it's not a game) that's pretty common, and runs well, take a look at Limewire. Obviously a virtual machine can't be as fast as native code, but they're definitely getting close. Macromedia Flash also uses Java (at least the Linux version does, anyway). At any rate, I'd like to be able to take a disc from one system and use it in another just as much as the next man, but then that would defeat the point of having multiple systems. Each game console, for example, has its own unique strengths, quirks, and so on. I like the dreamcast because it was fun getting Linux cross-compiled for SH4 and burnt to a CD. I like the PS2 because it uses a 297MHz R5900 (ohhhh, MIIIPPS), and has official commercial support for Linux. Running everything in a virtual machine would take those strengths away, since it wouldn't be possible to take advantage of them without breaking compatibility.
A solution to the problem with music today
Really......
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.
I'm still working on a clever footer.
No, I don't know the technical details, but yes, I'll agree that closer to the hardware means faster. Is that why so many games are still written in DOS?
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.
Ho! Haha! Guard! Turn! Parry! Dodge! Spin! Ha! Thrust!
As I see it, this is missing 2 things, neither of which Sun can really control.
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.
ZOMG I WOULD LOVE TO KNOW ABOUT YOUR FEELINGS ON MACINTOSH VERSUS WINDOWS, VI VERSUS EMACS, AND HOW YOU'RE NOT A DORK
As long as people are willing to code to the bare metal to squeeze as much performance out of their hardware as possible (and then achieve a few miracles beyond that) this won't catch on. Sure, the development costs will be lessened, but at a substantial hit to performance. This will kill any company's hope in an industry where everyone's convinced that graphics is more important than gameplay. It isn't, but that's still the marketing angle that everyone uses.
You see? You see? Your stupid minds! Stupid! Stupid!
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.
Guy who's done a lot of programming in assembly language AND a lot of programming in machine language, and is boggling at the notion that anyone could think that they're the "same".
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?
Coming soon - pyrogyra
Future advances in technology will never make the performance of Java games acceptable (at least for shooters, flight simulators, big real-time strategy games and other CPU hogs). You'll always be able to go much faster with natively-compiled, non-garbage-collected languages that let you get closer to the hardware, and, therefore, make better-looking, better-playing games.
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
Java is a sweet programming language. I can't stand C++. Hopefully if they can get this going (or at least produce a usefull API for lin/win/mac games) java will be a viable option for dong 'real' game programming.
autopr0n is like, down and stuff.
You are right, to an extent. As you say, C is far more portable. However, to make that happen, developers need to work their ass off to do it. I can't even fathom making a game, written in C, and supporting on Windows, Mac, Linux, FreeBSD, OpenBSD, NetBSD, BeOS, X-Box, Playstation, Nintendo, etc... etc...
;-)
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
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.
Go read the interview again, specifically the first paragraph. He *is* a marketroid, not a coder.
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
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?
When Java is run on servers, where a single program can run for an extended period of time without quitting, the JIT can often do extremely thorough optomization and get Java running nearly as fast as, and on occasion barely faster than, the equivalent C++ program. I don't find it particularly hard to believe that the next generation of JITs will be able to exceed C++ easily if they are rigorously optomizing. The problem is that user applications often don't run long enough for the JIT to do that serious optomization, and unless Sun has some very revolutionary ideas, games would suffer the same problem.
All of the posters saying how this can't be done, because of Java this and Java that are arguing a purely academic argument.
:
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.
NZ Electronics Enthusiasts: Check out my Trade Me Listings
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.
Are there games still being made in DOS? Could you name one or two? I'm not trying to challenge you here, I just wasn't aware of it. I'm curious what happens if I run them in Win2k. If they don't work, I'd like to try to find a DOS emulator that will make them work. If I could find that, I have a few games packed in a box somewhere I'd like to try to resurrect.
Any help here?
"Derp de derp."
Quake3 doesn't use java, it uses a bytecompiled version of strait C called quakeC. And that's only for game logic. Engine code is written, not in assembler but strait C as well. If they wrote it in assembler then they'd never have the ports to all the systems that they have.
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/
The GameCube uses "Mini-DVDs" instead of the larger ones used by the other consoles. If they want to create something that is cross-compatible with all of the current consoles, they'll either need to make all of the Java-coded DVDs small, or insist that people purchase a Q console if they want the best of both worlds.
(Q is a GameCube clone by Panasonic that can play DVDs. It is unlikely, however, that it will ever be sold outside of Japan.)
Remember "Bring 'em on"? *sigh
Anybody remember Ultra HLE? It's a N64 emulator. I never got the chance to muck with it because I never had a Voodoo 2 card, but what I read about it was very interesting. It didn't emulate the processor of the N64, instead it was a translator so that commands in the ROM went to native commands on the Voodoo card. A 'draw triangle' command on the N64 would be sent to the Voodoo card and translated to 'draw triangle' in the native hardware. This is different from trying to get the PC's main processor to emulate what the N64 processor would do.
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.
"Derp de derp."
Though it may be good for the consumers, and the developers, this will not happen. Nintendo, Microsoft, and Sony make their money from games that come out on their platform. They have no incentive to support a technology that will aid their competetors.
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
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).
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!.
Part of the problem with the game industry is that there are too many games in it. For now, it's okay because there are still lots of people not playing games yet, but eventually it'll turn into a market where there's 10 new games for every game player. Uh oh. I don't have $500 a month to spend on maintaining a game library.
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.
"Derp de derp."
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.
While we're still waiting for the Java OS, Sun comes with an even wilder idea. There ideas continue to impress, there accomplishments however, well that's another story.
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.
Ok. Games now have a few gigs of data. Why not just load a whole OS off the disc? Developers could get as fancy and cross platform as they want as long as they can port Linux or whatever to that console's archetecture. This would royaly piss of console makers, but who cares. Maybe consoles will become more like PCs where you can get the latest console every six months instead of every two years.
bash-2.04$
bash-2.04$yes "Don't you hate dialup connections?"| write USERNAME
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
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
Well-written C will be more portable. Well, if you write in Python, Ruby or Perl, it doesn't even has to be well-written to be more portable than Java.
Stop this train already. It is a nice language, but I think Java "portability" is a big hoax.
Whatever. FreeBSD can do the same, yet they have put together a native JDK. Thats a lot of work... so there must be good reason for it.
In fact, it DOES make sense that things like turn based and realtime strategy games could benefit from being written in Java, if you've got the right JIT behind the JVM running the code. The same could be said of several other genres of game. Now, a FPS or something in that same class would be a very hard sell- not impossible, but currently very improbable.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
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?
Life is complete only for brief intervals in between toys or projects -- John Dalton
using the NIO to load textures into video memory
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.
Life is complete only for brief intervals in between toys or projects -- John Dalton
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.
HLE in this case stands for High Level Emulator. It's emulating the API (like Wine, which emulates the Windows API) rather than being a machine emulator.
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.
deus does not exist but if he does
Sure some games do use C++, like those massive RPG games, but most games use C and Assembly.
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
If you use Linux, please help development of Autopac
And a lot of GP3 was written in assembler, though we all know how buggy that turned out...
graspee
Console games dont use directX unless its trying to be a PC port.
Face it, Console developers write their own libraries, they have their own tools, and they write alot of the game in assembly.
If you use Linux, please help development of Autopac
You can do AI in any language,
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.
If you use Linux, please help development of Autopac
The beauty behind consoles is that when programmers make games for them they can optimize the graphics and gameplay to get the best possible experience for the game. Using java on top of their built in functions would dramatically slow down gameplay, quality, etc. If they go this route, I will truly have a reason never to own another new console.
"In some cases, Java runs faster than native code"
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
Two consecutive Slashdot stories:
-- Platform Independent Gaming?
-- Ask Slashdot: Most Outrageous Vendor Lie Ever Told?
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
"gee, will computers get faster? (hint, the answer starts with a 'Y')"
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
When you talk about japanese console developers, they will NEVER do that, they always push the limits of the hardware.
Thats why console games keep looking better and better and PC games all have the same tired look
If you use Linux, please help development of Autopac
In order to have seamless cross-platform, you have to have a very significant abstraction layer between the application and hardware. You have to have a layer that adapts to the specific querks and architecture of the underlying machine and presents a uniform interface to the application.
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.
"I'll just chip in a bit for RedHat: I actually have that installed on my university machine." - Linus, '95
"... just someone get finished on an x-box emulator and be done with it ... i wanna play halo!!!"
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
Illwinter have accomplished something very much in spirit of what this discussion is about with their Dominions game. This game works on Windows, Linux, Solaris, IRIX, and HP-UX.
:)
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
Blearf. Blearf, I say.
Java isn't an OS. The main limitation for video game systems is always the graphics speed, which as others have stated, is something Sun has been working to improve. The question then is, do you believe vendors will trust MS enough to support .NET's intermediate language in their consoles? Maybe X-Box developers, but who knows how X-Box will fair in the future.
.NET on a console?
.NET makes it easier to switch between the two schemes, so you could (say) write all your game control logic in script and run it through the .NET engine, banging through to native code for the real work, but that's still a lot of wasted cycles.
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
Coming soon - pyrogyra
Still....point was the lack of java
first, what are non speed critical sections of a game? the splash screens, setup menu? the actual playing area, which I'm hoping is a majority of the game is speed dependant. they tend to heavily use the processors available, and any they can get their hands on (video, CPU, audio, etc).
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.
I find the /ignorance almsot amusing.
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
What's that saying: 90% of a programs execution is in 10% of the code? I think you need to learn a little about optimization and speed issues. The game will spend most of it's time in the speed critical section - that's why it's speed critical - but that section will not make up much of the code for the application.
the actual fact is that a very insignificantamount of games are actually produced by java.
Originally a very insignificant amount of games were written for Windows (they were all for DOS even after Windows came out), but time changes things. As time progresses I'm sure you will start to see games written in Java. Right now game development shops are familiar with C/C++ and assembly which encourages them to choose C/C++ - technical merits are not the only considerations for a selection of language.
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
That's because you attribute fast performance and responsiveness to C/C++ apps and don't recognise them as Java apps. You did realise that Java can take on the native look and feel and become completely indistinguishable to native apps right? :)
Of note was this article (actually this .pdf) that benchmarks several Java JIT environments, a Java native compiler, Visual C++ and Intel's C++ compiler. The optimized hardware accelerated OpenGL benchmark was nearly identical to the C++ version. Don't forget to read the errata which addresses his Java bias and other issues.
Regarding your Quake comment, I'll point out that Java was implemented for mod development for Quake 2. Definately not the game itself, but still it exists as a another example of how Java can be used in game development.
Bleh!
I think you need to learn a little about optimization and speed issues.
:)
i would never discount that.
The game will spend most of it's time in the speed critical section - that's why it's speed critical - but that section will not make up much of the code for the application.
so, the code that executes when i'm moving my arrow key/joystick whatever to move the little guy arcross the hilly 3D terain trying to capture the coins or whatever while basically running all over the place... that's not speed critical code? maybe just the rendering of all that crap? is that speed critical?
You did realise that Java can take on the native look and feel and become completely indistinguishable to native apps right?
could you point me to one that I could evaluate? like i said, i haven't seen one yet.
The input methods are not speed critical as they take almost no processing to complete. The graphics rendering is speed critical but you need to look more fine grained than that. The specific area to be optimised differs for each application. It is almost always in a repeat loop though and often in a nested repeat loop because that code is executed repeatedly. It may be a part of the rendering code, particularly for calculating what is in the field of view.
Optimisation is really not my area so you'll have to do some independant research on this - there are plenty of publications about it. A quick google search should keep you pretty busy. The key thing to remember is that there is no need to go all out optimising everything - you only need to make the application run fast enough so that it is acceptable to the user and probably a little faster for good measure. Users almost always judge the speed of the application on an impression and not the actual speed of the application. You are better off spending time designing an efficient user interface rather than trying to optimise everything.
could you point me to one that I could evaluate? like i said, i haven't seen one yet.
Well pretty much any well written Java app on Mac OS X - the Java support on X is very impressive. Of particular note though is World Book Encyclopedia for OS X which was written in Java (there must be some specific libraries in C as it is not currently available for Windows). It was demoed during the keynote at MacWorld and nobody realised it was written in Java.
Java support on Windows isn't as good but is rapidly improving. I actually don't know of anything that is readily available that really shows off what Java can do (my development work is yet to be released ). Actually, Tomcat would be a pretty good example. It's written in Java and is used in industrial strength servers. Admittedly it doesn't use the GUI elements much which is where Java is at its slowest right now, but it's still quite a testimony to the fact that Java can perform extremely well.
C is faster in GUI work but using the native look and feel of Java is very effective and is continually improving. Long term prospects are really looking good. If you can, have a play with an OS X machine some time - the Java support is brilliant and Suns implementation is struggling to catch up.
Yes, OK, whatever, but you missed my point-
HOW CAN IT RUN FASTER THAN NATIVE CODE? !!!
I mean, does Java auto-overclock your computer or something, or turn into a quantum computing device?
graspee
Me and a friend (and two korean guys) are doing a game type thing in Java with J3d. It's not slow at all, even on my laptop (celeron 600). It's not that complex so far, but the fact is with Just In Time compling and hotspot compiling java can be as fast as C++. You also have to know what your doing.
autopr0n is like, down and stuff.
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.
public class SlashdotDiscusser{
public static void main(String args[]){
while(true){
System.out.println("Java is slow.");
System.out.println("C++ is sooo much faster than Java.");
System.out.println("Java is nice for some things, but for any real task...");
System.out.pri ntln("Jon Katz sucks!!");
}
}
}
}
autopr0n is like, down and stuff.
that's basic code. (basic code that pokes values into memory, but basic code none the less)
the assembly code:
mov ax, bx
mov bx, cx
mov cx, dx
Translates directly to:
89 D8 89 CB 89 D1 89
autopr0n is like, down and stuff.
Sega made the dreamcast.
autopr0n is like, down and stuff.
Just like how you can't see the sourcecode to any compiled java program, moron.
autopr0n is like, down and stuff.
The major problem on my machine at work (a P2 366 with 128MB) is the amount of memory that Java-applications use. The speed of the application is usually acceptable once it's swapped in.
Some good examples are jEdit, a very good Java-based text editor and intelliJ IDEA, a great Java IDE. I've never seen a pure Java app that blended in perfectly with an OS however.
The Drowned and the Saved - Primo Levi
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.
If one wants portability, one could always code in Python and use PyGame. Python does everything Java does, other than having management-friendly buzzwords, and has a more civilised syntax too.
So that you can port applications from the PC easily.
In fact I currently have a large amount of Java code that we are considering using J# to compile down to .NET to get acceptable performance. Processor independent binary distrbution is not something I am particularly concerned about. The code will only ever run in a small number of datacenters on specified hardware.
I am told that you can even change the VM manager on .NET, how I don't know. However the real constraint comes down to transparent vs explicit memory handling. I suspect that Microsoft's VM is probably close to optimal on what can be done for transparent memory management, however as you point out that is not necessarily acceptable performance for games.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
IndirectX?
A consistant software environment between Windows and Linux? Hey, sure, whatever. Sounds like a good idea. But on consoles? Not just no but HELL no! The people who think this is a good idea are the same people that can't understand why people buy consoles instead of PCs to begin with.
When all is said and done consoles are popular because they provide a consistant gaming experience. A game developed for GameCube (for example) will run on my GameCube exactly the same way it does on my neighbor's GameCube, and they both run the same way as the GameCube down the street. I know I can go out and get a copy of Super Smash Bros. Melee, put the disk in, turn on the console and start playing. I don't need to study the fine print to find the hardware requirements as that's all taken care of by one word on the front: GameCube. I don't need to wait for the game to figure out what hardware I have because the publishers already know exactly what I have. This can only happen when the hardware is proprietary and consistant among all users.
When the hardware becomes a commodity (as it is with PCs), you no longer have that consistancy. My copy of Half Life runs differently on my computer than my neighbors computer (which has a little more RAM), and we're both different from the experience the computer down the street (with a different video board) has. I can't just walk into Best Buy, grab a copy and walk out. Instead I have to study the minimum and reccomended hardware requirements and wonder where exactly my computer fits into all that.
But even more damning is the effect that commodity hardware has on game publishing. Time and time again programmers have shown that if you give an inch they take a mile. Many (if not most) software (especially games) are designed to look best on hardwre that was released last week, and if you don't have that hardware you're up a creek. A PC bought this year will just barely be able to play games released next year and won't be able to play games two years down the road. And most of that bloat is extraneous crap, insignifigant improvements picture or sound to the point that most of the games on the market today are aimed to sell based on the Ferret Effect ("Ooh! Shiney!").
If you commoditize console hardware you'll end up with a market that looks just like the PC game market. Instead of games being written for a console they're instead written for an ideal hardware platform. Suddenly you'll need to know quite a bit more about your hardware than just the manufacturer. A console on the market today will be obsolute in a year instead of 5-7. And console prices will jump up to damn near double their current prices as hardware manufacturers no longer have 5-7 years to recoup losses from low release prices. More and more game publishers will aim for the quick buck generated by tweaking the polygon count instead of focusing on outdated things like "plot" and "playability."
Replayability? Why bother to include that in a game? As time passes and your hardware improves, you'll be less and less able to play older games anyway. Try playing MechWarrior on a PC capable of playing MechWarrior 4. WarCraft on a PC capable of playing WarCraft III. Your old hardware could play them fine, but why would you hang on to it since the new hardware will play the old stuff anyway? Besides, you had to sell it to afford the new console...
Suddenly the console market falls through the floor as gamers decide that with all this fustration they may as well use their PC instead. Many others blow the dust off their old consoles as they long for the days of just having to push the power button to play a game. Besides, those games are from a day when games were meant to be replayed.
Making the console market a commodity will take away all the reasons the console market has been successful to begin with. Unlike PCs they're easy to use, consistant, relatively inexpensive and won't be obsolete for at least half a decade. And no one company has a monopoly on the software environment.
Sure, well-written java is usually a little bit slower than well-written C, which is usually a little bit slower than well-written assembler. That doesn't mean that one should forever try to use assembler (or C). Just as important as speed for game-development is:
In all these three cases, Java will be able to help. The only thing that speaks agains java here, is it's lack of raw speed. But that isn't really true anymore. Java, by itself is already quite respecably fast. It is not as fast as C (unless you count some weird benchmarks probably written just to show that), but it's not too far below either.
Secondly, you don't need to optimize everything, only the time-critical pieces of your code. And for most gaming purpoces, the speed-critical parts are the drawing routines. Making that as fast as in C is pretty simple. You build a wrapper around openGL or some other graphics library, and use that from java. There you go...
And that is exactly what a java gaming platform would look like. It would be a collection of well-defined API's for accessing your hardware in a controlled, but efficient manner.
Is it really going to happen? Nobody knows just yet, but I wouldn't dismiss it right away. The idea is good, the question remains to be seen whether the API's will be equally good, and developers adopt them.
Are you pointing to a debug/design flaw in Sun's implementation and saying that it is a fundamental flaw in the Java language? If so, please explain why.
I don't care if it's 90,000 hectares. That lake was not my doing.
I'm pretty sure what you call microcode he calls machine language; what you call machine code is BASIC -- that is, a human language that another program can interpret and run, not a machine language that runs on its own. Indeed, your BASIC program does not do what you think it does; the values in the DATA statement are the same program as the assembler example you give, but the BASIC program you say is "identical" is mearly the loader -- a loader that needs an interpreter to work! Your example is twice removed from machine code.
If all this should have a reason, we would be the last to know.
You've obviously never patched binary code where you didn't have the source. I've had to do that, and yes I had an assembler at the time. Had a disassembler, too :-)
Nice assumption. Wrong, but a good shot anyway.
Yes, I have patched binary code where I didn't have the source. Both recently on production Windows code where we had lost the source, and back when I was hacking Sinclair Spectrum games.
I'm pretty sure what you call microcode he calls machine language; what you call machine code is BASIC -- that is, a human language that another program can interpret and run, not a machine language that runs on its own. Indeed, your BASIC program does not do what you think it does; the values in the DATA statement are the same program as the assembler example you give, but the BASIC program you say is "identical" is mearly the loader -- a loader that needs an interpreter to work! Your example is twice removed from machine code
Well, duh. I'm so sorry for providing a tool as well as a description. Don't you think I knew that?
Would you also like to point out that it should have been FOR I = 0 TO 11 instead of 0 TO 19?
Simon
Coming soon - pyrogyra
Platform
Independent
Gaming...
So, what you're saying is that Java is a PIG.
Well, duh...
"Make it ten--I am only a poor corrupt official."
--Captain Louis Renault (Claude Rains), Casablanca
Well, we do run an MMORPG (we prefer persistent online world) on Win32, Linux and Solaris with no recompilation. First person 3d, ~50fps on a 1.4 ghz w/ geforce2, etc. Ask someone who went to the GDC.
You thinking it's a hoax doesn't change the facts.
Well, it is not that I *think* it is a hoax. I experienced it. Haven't programmed in Java for about a year already, it might have changed. We used to make Java "compatibility workarounds" in our Java programs (mostly thanks to AWT, Swing wasn't around yet)
:)
I'm glad things have changed, but it is irratating that Sun advertises "cross-platformness" a couple of years ago, which was simply laughable.
And, you don't have to tell me it runs 3D 50FPS on geforce2. I have confidence in Java's 3D performance, afterall, it is just another pretty thin layer to very fast graphics accelerators