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.

452 comments

  1. HAHA by Mushy · · Score: 0

    It's just JINI in a new bottle (pun intended)

  2. before anyone starts moaning about java.... by Anonymous Coward · · Score: 0

    At last year's JavaOne conference, there will many demos involving high speed graphics (many using the same flight sim clip) that came out with Java 1.4. Also, Sony announced at the show last year that PS2 will have support for Java. Should be interesting what comes out at this year's JavaOne, which starts tomorrow.

    1. Re:before anyone starts moaning about java.... by ishmalius · · Score: 1

      Yeah, I think that Java could keep up just fine
      with any game or collaborative logic. If the rendering is offloaded to other software and hardware, the "under-the-hood" stuff is relieved of a lot of performance issues.

    2. Re:before anyone starts moaning about java.... by oldwarrior · · Score: 0

      HaHaHaHaHaHaHaHaHoHoHoHoHoHoHoHoHoHoHo...phew.

      --
      If it were done when 'tis done, then t'were well it were done quickly... MacBeth
  3. More information here... by ImaLamer · · Score: 3, Funny

    I've seen this story of before

    1. Re:More information here... by capnjack41 · · Score: 1
      If they get full support for it I can finally get rid of that windows gaming partition!"

      From your Xbox?

    2. Re:More information here... by ImaLamer · · Score: 0, Flamebait

      -1 redundant yet I was the first to post this, odd.

    3. Re:More information here... by sloanster · · Score: 1

      (shrug) what's an xbox?

  4. if it's true.. by 56ker · · Score: 1

    I'm amazed - if it isn't well I'll just add to the list of nice sounding things that didn't work out in the end.

    1. Re:if it's true.. by Anonymous Coward · · Score: 0

      I would be amazed if they can pop the same CD into a GameCube. ;)

      (FYI The GameCube take a special sized DVD...)

    2. Re:if it's true.. by dirty · · Score: 1

      From what I understand (I don't have a gamecube so I can't verify) GameCube can take standard size dvd/cds, it's just that most of the games are on the smaller size.

      --

      -matt
    3. Re:if it's true.. by i_m_sane · · Score: 1

      no it cant, the game cube itself is only 4inc wide so i can only take 3.5inc discs

      Panasonic is releaseing a full sized gamecube that will also play DVDs but that wont hit the us for another few months.

      I would of included links but im lazy.

      --
      Adam Sane sanity is a dirty job, but somebody has to do it.
    4. Re:if it's true.. by Schnapple · · Score: 1
      Panasonic is releaseing a full sized gamecube that will also play DVDs but that wont hit the us for another few months

      No, sorry - that one's never coming here.

  5. Why bother? by Anomolous+Cow+Herd · · Score: 1
    Windows works fine for my gaming needs. And, it has the added bonus of being written in a fast language like C++ and natively compiled. Sure, you can do 3D graphics in Java, but it won't be playable.

    Besides, if you really need a reference on how well Windows serves as a gaming OS, ask CmdrTaco. He sure seems to like playing Diablo II and other such timewasters in M$ land.

    --

    "I don't know that atheists should be considered citizens, nor should they be considered patriots." - George Bush
    1. Re:Why bother? by Anonymous Coward · · Score: 0

      Um, have you looked that full screen mode support in JDK 1.4? Faster than C++, my man.
      Check it out.

    2. Re:Why bother? by Anonymous Coward · · Score: 0

      Quake3 uses Java. Well, where it counts it doesn't even use C++, like you advocate. It uses assembly. But there are many many parts of games that can use Java (e.g., menu, help, networking, encryption). So, while you're still debugging pointer errors in C++, the Java developers are done and shipping their Java-wrapped assembly.

    3. Re:Why bother? by spectecjr · · Score: 0, Flamebait

      Um, have you looked that full screen mode support in JDK 1.4? Faster than C++, my man.
      Check it out.


      BULL SHIT.

      If for no other reaso than because memory pooling is a bitch on Java.

      Tell ya what... why not crawl back into your hole you Sun Astroturfer?

      --
      Coming soon - pyrogyra
    4. Re:Why bother? by Pussy+Is+Money · · Score: 1

      Actually the Java developers are still trying to get people to upgrade to the new version of the JDK which supports stuff like, oh, I don't know, setting the creation date on a file.

      --
      Pushin' 'n dealin', shovin' 'n stealin'
    5. Re:Why bother? by Anonymous Coward · · Score: 0

      Wow what an insightfull comment. The previous post, pointed out an article with some good merits, and all you can do is come back with an explative....

      C++ will NEVER be as fast as Assembler. Assembler will NEVER NEVER be as fast as pure machine code.... Sound familar. Who programs in machine code anymore? Not me.

      I don't know if I belive Suns claims either, but I am not going to shoot my mouth off, and put someone else down for my ignorance. You will look like a fool if/when they port Quake III to Java 1.4.

      Later
      Steve Michael
      smichael@netcapade.net

    6. Re:Why bother? by bakes · · Score: 5, Insightful

      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!
    7. Re:Why bother? by Anonymous Coward · · Score: 0

      Assembler *is* machine code.

    8. Re:Why bother? by Anonymous Coward · · Score: 0

      Wrong. What ARE they teaching in schools these days?

    9. Re:Why bother? by Anonymous Coward · · Score: 0

      No - Assembler == Machine Code.

      Maybe a macro-assembler adds a litle bit of abstraction - but assembly language is at the same level as machine code.

    10. Re:Why bother? by Anonymous Coward · · Score: 0

      You are completely wrong.

      Assembler: Uses mnemonics and symbols to represent machine instructions.

      Machine code: Raw bits.

      They aren't even close to being the same thing, even if you don't throw in stuff like macros.

    11. Re:Why bother? by Anonymous Coward · · Score: 0

      But assembly code is mapped 1:1 to bits. There's no parsing and optimization. They are totally equivalent. It's like saying that a sentence in English is on a different level than that same sentence rot-13'd.

    12. Re:Why bother? by Anonymous Coward · · Score: 0

      But assembly code is mapped 1:1 to bits

      So what? A computer does not run assembly code directly. It must be translated first. Therefore they are not the same thing.

      I'm aware that there's tendency to get sloppy with terms and use "assembly language" when you mean "machine code" and vice versa. That doesn't make it right.

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

    13. Re:Why bother? by Anonymous Coward · · Score: 0

      You don't know what you're talking about.

      DOS still is technically the best platform because Windows is horribly bloated. It's just extremely difficult to code for because there's no compatibility layer a programmer can use (like DirectX or OpenGL).

      As always, a DOS program with direct hardware access to your favorite 3d accelerator will beat a Windows program with lower system requirements.

      The performance distance between DOS and Windows is considerable, but it's worth coding in Windows because of technical reasons. However, the performance distance between Java and C++ is just huge and there's no major reason to take this step, specially if you consider the total lack of (and virtual impossibility of writing) media APIs in Java.

    14. Re:Why bother? by Anonymous Coward · · Score: 0

      Oh, and by the way, there ARE such things as optimizing assemblers. They used to be quite common.

    15. Re:Why bother? by bakes · · Score: 2

      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!
    16. Re:Why bother? by Warped-Reality · · Score: 1

      Wrong again.

      ASM code translates _DIRECTLY_ into machine code - it's just a different way of writing it (i.e, mov ax, bx as opposed to A2 FF BC)
      (given you're using 'pure' ASM as opposed to a macro assembler)

      --
      This is not the greatest sig in the world, no. This is just a tribute.
    17. Re:Why bother? by spectecjr · · Score: 1

      C++ will NEVER be as fast as Assembler. Assembler will NEVER NEVER be as fast as pure machine code.... Sound familar. Who programs in machine code anymore? Not me.


      You're a schmuck. Assembler IS machine code. There is *no* difference, other than one is written as binary, the other as text.

      Now go away and stop acting like you know what you're talking about.

      --
      Coming soon - pyrogyra
    18. Re:Why bother? by damiam · · Score: 4, Informative
      And, it has the added bonus of being written in a fast language like C++ and natively compiled.

      When running a game, the main overhead isn't the speed at which the instructions are executed by the CPU, it's drawing the graphics. As long as Java can use hardware acceleration with the video card, the speed of the language hardly even matters. Anyway, JIT Java can get pretty fast if well compiled.

      --
      It's hard to be religious when certain people are never incinerated by bolts of lightning.
    19. Re:Why bother? by spectecjr · · Score: 2

      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
    20. Re:Why bother? by Anonymous Coward · · Score: 0

      > 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 don't know any recent games which were written for DOS, but yes, it is technically much more appropriate than Windows for fast applications without any need for multitasking. Unfeasible for current games, but much more appropriate.

      I understand what you mean now. But do to the lack of universal Media APIs for your Java games to use, I think it's going to be impossible to accomplish this. Unless we've got things like accelerated 3d on all Java platforms the game is supposed to run on, we can forget about the idea.

      I believe we'll have to keep using libraries like SDL along with OpenGL (while coding in C or C++) if we intend to have fast, portable games.

    21. Re:Why bother? by Anonymous Coward · · Score: 0

      You're missing the point entirely.

      "LD HL,0" is not the same as "33,0".

      If they were the SAME you would not need an assembler.

      Arguing that assembly language and machine code are the same is like arguing that English and French are the "same", since you can translate one into the other, often with a 1-1 mapping of words (the analogy fails slightly, since there isn't always a 1-1 mapping, but generally a word in one language will map directly to a word in the other).

      If one form requires translation (human or machine) to be put into the other form, the two forms are not the same. That is all.

      Many C statements will translate almost directly into ASM statements. Does that mean that C and ASM are the "same"? It does not.

    22. Re:Why bother? by sloanster · · Score: 1

      I find this interesting and useful.

      I hope it works out and catches on - if so it would be a much better programming target than whatever ms is hyping at any given time.

      Yes, Virginia, there are gamers who don't even _own_ a windoze pee cee, and would rather not be pressured to obtain one just to play the latest game.

    23. Re:Why bother? by Anonymous Coward · · Score: 0

      That's a mighty big "given", by the way. When assembler was king, macros were the way to go. Many macros (especially utility ones intended for reuse) did things like automatically pushing all the registers (or at least all the ones used by the macro) onto the stack, since they had no way of knowing what ones would be in use at the time the macro was inserted. Afterward, all the registers except the one holding the result would be restored. This could and did affect performance to some degree.

    24. Re:Why bother? by Com2Kid · · Score: 1

      Now that all depends.

      The CPU is a limiting factor in some types of games, notable those that have complex physics engines. Just because Quake 3 can run in excess of 200FPS and is compleatly graphics card limited now days does not mean that ALL games are that way.

      Hell playing multiple videos in different parts of the screen starts sucking away at your CPU power (if you are stuck with an Overlay graphics style system that is. May be different otherwise, I have no idea. ^_^ ). Hell applying basic transformations and morphs to the position/shape of the video play back will (most likely) require CPU usage as well.

      Hopefuly with large storage formats, more games will begin to use video too. :)

      Then there is AI. . . . . How is Java going to handle the VASTLY different ways that the CPU can do AI routines. Hell screw that, how is the poor PROGRAMMER going to handle the fact that his great new AI routine that totaly and compleatly Kicks Ass when running on the hardware of, say the Playstation 2 compleatly blows on the X-Box? Or vis versa, which ever.

      Use a lesser AI routine? Or code two versions of it one for each console? Yup, that sure saves him a lot of work. . . .

      Of course you can argue that it would have been done that way anyways, but under this Java system no longer will console programmers be as willing to go 'down to the metal' of the machines that they are programming for.

      Of course in all fairness most games that are planned as being multi-plateform are made to the least common denominator in the first place with only minimal optimizations for each system it is ported to.

    25. Re:Why bother? by spectecjr · · Score: 0, Flamebait

      "LD HL,0" is not the same as "33,0".

      If they were the SAME you would not need an assembler.

      Arguing that assembly language and machine code are the same is like arguing that English and French are the "same", since you can translate one into the other, often with a 1-1 mapping of words (the analogy fails slightly, since there isn't always a 1-1 mapping, but generally a word in one language will map directly to a word in the other).

      If one form requires translation (human or machine) to be put into the other form, the two forms are not the same. That is all.


      Assembly and Machine Code are equivalent.

      Higher-level languages are not.

      For example:

      typedef struct tagData {
      int data1;
      char data2;
      } TAGDATA;

      void DoSomething (TAGDATA* a) {
      a + 1;
      *a.data = 1;
      }
      ----------------

      This cannot be expressed directly (typically) in assembly language or machine code, with a 1:1 mapping of constructs.

      Why am I bothering? It's quite clear that you're arguing semantics here, when the fact is that they ARE equivalent, and generate IDENTICAL results. So what if you have to put assembly language through a translator? Machine code typically has to go through translation too (or are you forgetting microcode?). The only difference being that in one case you're doing it in your head, and in the other you're getting something else to do the grunt work for you.

      It's like saying that there's a difference between pins on an IC and the labels you give those pins, because the pins themselves are the lowest level data.

      Well, sure, but you try putting data through the voltage rails and see how far you get. You're constrained by the design of the system. Assembly language is an expression of that design.

      Next thing you're going to say is that ASCII is less efficient than binary, because binary can represent any number, but ASCII only represents the codes that have been assigned to it.

      Simon

      --
      Coming soon - pyrogyra
    26. Re:Why bother? by TheAJofOZ · · Score: 3, Insightful
      But do to the lack of universal Media APIs for your Java games to use

      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.

    27. Re:Why bother? by Fnord · · Score: 2

      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.

    28. Re:Why bother? by Zeinfeld · · Score: 5, Interesting
      ]C++ will NEVER be as fast as Assembler. Assembler will NEVER NEVER be as fast as pure machine code.... Sound familar. Who programs in machine code anymore? Not me.

      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/
    29. Re:Why bother? by letxa2000 · · Score: 2
      Many C statements will translate almost directly into ASM statements. Does that mean that C and ASM are the "same"? It does not.

      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.

    30. Re:Why bother? by PierceLabs · · Score: 1

      Oh brother... I remember hearing this same argument back during the days of Direct3D. Why is it that people who seem to know the least about the topic always spread FUD and ignorance to the community? I've just never understood such negativity. Well Anomolous Cow Herd I would simply advise you to educate yourself some more on Java in particular on JNI because it is quite possible for someone do do a game in Java (especially JDK1.4) that uses the same feature set as OpenGL or Direct3D and is quite "playable."

    31. Re:Why bother? by Anonymous Coward · · Score: 0

      Since Java3D is a wrapper for "OpenGL" (which strictly speaking is a standard, not a program or library), you clearly have a library for OpenGL hardware access. This library is probably written in C.

      I don't see why people would use Java+Java3D instead of C++ and SDL, specially because they'll most likely require performance from the app.

    32. Re:Why bother? by TheAJofOZ · · Score: 3, Insightful
      Since Java3D is a wrapper for "OpenGL" (which strictly speaking is a standard, not a program or library), you clearly have a library for OpenGL hardware access.

      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?

    33. Re:Why bother? by Anonymous Coward · · Score: 0

      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.

    34. Re:Why bother? by Anonymous Coward · · Score: 0

      Guess you didn't notice that the 3D racer built in java runs somewhere around 40fps on a less than maxed system.

      Hunt around, I don't think it's on that site. I think it's on the java 3d development site.

    35. Re:Why bother? by FrostedChaos · · Score: 1

      hahahaha.... where did you do "a lot of programming in machine language?"

      Assembler and machine languages are the same, except for some "prettification" by the assembler. Get with the program, kiddo.

      --
      "Any connection between your reality and mine is purely coincidental." -Slashdot
    36. Re:Why bother? by thomas.galvin · · Score: 1

      /*
      Why is it that people who seem to know the least about the topic always spread FUD and ignorance to the community?

      I blame it on the Automated Slashdot Disscussion Module: for the sake of brevity, I've left out the "topic == microsoft", insertRandomBitchSessionAboutAds(), insertRandomBitchSessionAboutCowboyNeal(), and insertExtravegantClaimsAboutMyCodingAbility() portions of the code.*/

      #include <string>
      #include <vector>
      #include <iostream>

      using namespace std;

      string topic;
      cin >> topic;

      if (topic == "java")
      {
      //vector<string> FUD;
      vector<string> arguments;

      arguments.push_back("Java is slow.");
      arguments.push_back("C++ is sooo much faster than Java.");
      arguments.push_back("Java is nice for some things, but for any real task...");
      //...

      for (int i = 0; i < arguments.size(); i++)
      {
      cout << arguments[i] << "\n";
      }
      }

    37. Re:Why bother? by spectecjr · · Score: 2

      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.

      Yet again though, the same issue comes up:

      Why would you want to run .NET on a console?

      Now, admittedly, .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.

      .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
    38. Re:Why bother? by Phantasiere · · Score: 1
      Quake3 [...] uses a bytecompiled version of strait C called quakeC
      Nope. QuakeC was a C-like language developed for Quake 1. Quake 3 use ansi C compiled into bytecode to be run on a VM, or compiled into a native shared library.
    39. Re:Why bother? by high · · Score: 1

      I think quake3 has left bytecode and gone for native formats such as .dll's and .so's. In quake1 they used bytecode that compiled to a file called progs.rc.

    40. Re:Why bother? by Fnord · · Score: 2

      Still....point was the lack of java

    41. Re:Why bother? by mark_lybarger · · Score: 2

      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.

    42. Re:Why bother? by TheAJofOZ · · Score: 2
      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).

      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? :)

    43. Re:Why bother? by mark_lybarger · · Score: 2

      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.

    44. Re:Why bother? by TheAJofOZ · · Score: 2
      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?

      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.

    45. Re:Why bother? by Aapje · · Score: 2

      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
    46. Re:Why bother? by dashjosh · · Score: 1

      ...gamers knew that the best gaming environment, without question, was DOS.

      The gamers might have loved DOS, but programmers knew about the evil workarounds it required just to get more than 640k of memory.

    47. Re:Why bother? by Horn · · Score: 1

      Actually, JC likes using assembly. Check out the quake1 source release and the tools that came with em.

    48. Re:Why bother? by Zeinfeld · · Score: 2
      Why would you want to run .NET on a console?

      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.

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

      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/
    49. Re:Why bother? by Anonymous Coward · · Score: 0

      It's just a shame it crashes so easily. I'm off to the gamecube.....

    50. Re:Why bother? by Anonymous Coward · · Score: 0

      ASM will never be as fast as machine code. this does have a little logic to it. certain assemblers output different machine code. it MIGHT have a performance impact in certain cases. (say one way has a byte more of code. To load up that instruction, you DO need a memoruy read) it would be hard to argue, but it IS arguable.

    51. Re:Why bother? by Schnapple · · Score: 1

      Actually, Quake 3 has always had the ability to do both, though Carmack and the boys have always reccomended people use the bytecode to release MODs with and keep the native files for server operations (where you might need to make new files and such, which you can't do with the bytecode).

      So:
      Quake 1 - bytecode
      Quake 2 - native code
      Quake 3 - both

    52. Re:Why bother? by Anonymous Coward · · Score: 0

      As some other person mentioned, an AI engine is written in a language, and the engine itself may have its own "language" (a.k.a. "script") to drive it.

      So what CPU runs AI has as much impact as what CPU is tabulating your score. In other words, none.

      HOWEVER -- and this is the big however -- some games are extremely AI intensive. Battlecruiser Millennium comes to mind (note: will not engage in debate on quality of AI or of game, so don't bother). Graphics-intensive games that use hardware acceleration can get a native speed boost from the hardware.

      The only such "native speed boost" available to an AI engine is code optimization. Which to squeeze the most out of requires tailoring to a CPU instruction set (if you want to go that far).

      Java abstracts this. You have the (hopefully) well-optimized JVM trying to run (hopefully) optimized bytecode, perhaps using a JIT compiler that (hopefully) does a decent job optimizing itself...

      Too many hopefullys.

      Me? I'm waiting to see the .NET counter-proposal on this one.

    53. Re:Why bother? by Rick+the+Red · · Score: 2
      Couldn't afford an assembler at the time, huh?
      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 :-)

      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.
    54. Re:Why bother? by spectecjr · · Score: 2

      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
    55. Re:Why bother? by Anonymous Coward · · Score: 0
      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. Ahh yeah, more crap put out by compiler writers. This is basically rubbish, and you know it. If you dont, you dont know what you're talking about. Their idea of optimising code is writing it, compiling it with -S and seeting if you can write it in a way which optimises it better - it works, but has NEVER in my experience produced cleaner code than poperly written asm.

      At worst, a crap assembly program will be slower than a good c program, but its just as easy to write a crap c/c++ program (bad algorithm, bad flow choices) that will compile into a slow executable.

      Who cares, just get a faster cpu or overclock it, right? Typical PC answer, force the user to upgrade rather than getting the software right.

    56. Re:Why bother? by Anonymous Coward · · Score: 0

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

      Then why is Sony a key partner developing the Java Game Profile???????

  6. Game Cube by emn-slashdot · · Score: 1

    I don't think the ps2 and the game cube even use the same type of media... Once again Sun has put the goal too high.

    --
    -EvilMonkeyNinja
    Mild Mannered Host by Day
    Wild Hammered Programmer by Night
    1. Re:Game Cube by penguin_punk · · Score: 0

      But that's exactly it. Too many consoles, and the game developers have to either decide which platform to support 100% or work 110% and get the game working on more than one platform. The last game console I actually bought was a NES and I have watched my freinds throughout the years spend good-earned money on one console only to find that it doesn't support the game they want (or that the game they want doesn't support the console they own). With a universal gaming 'OS' so to speak, I could throw out my NES and buy a new system that may be the cheapest on the market (I don't play games often. obviously) While some of my freinds could go out and buy the latest top-of-the-line model of the newest playstation, and they may have better graphics, more fps, and a better rendering engine for the 'realistic look'.

      It won't kill competition, I believe it would encourage it. Instead of console makers spending time and money pushing game developers to support their hardware, they don't have to worry about the games, but worry about making them look better on their equipment.

      I am not means a gamer, but those are my thoughts.

      --
      HURD - Hurd's Under Research & Development
    2. Re:Game Cube by emn-slashdot · · Score: 1

      "A little less talkie, a little more shut the hell up"

      The actual media that the game is on for the game cube is a little tiny (possibly DVD) disc. It's not a standard format DVD disc. Each console, (X-box, ps2, game cube) USE A DIFFERENT FORMAT AND MEDIA TYPES. I don't care how cool your software is, you can't put a floppy in a CD-ROM drive... or a Mini-disc in a DVD.

      It just doesn't work. There will never be a single media container that goes into all the popular consoles. The reason is all of the companies in the market want to be the only company in the market. If you believe otherwise, you need a head check. Look at the past.

      --
      -EvilMonkeyNinja
      Mild Mannered Host by Day
      Wild Hammered Programmer by Night
    3. Re:Game Cube by Anonymous Coward · · Score: 0

      it doesn't matter what kind of media the console uses. This is for DEVELOPERS. That's right its so they can simply copy what they have done to the different media formats and know that it will run just fine. It isn't for consumers who plan on buying one game and using it on 50 consoles.

    4. Re:Game Cube by MayonakaHa · · Score: 1

      Correct.
      The GameCube disc is actually a 3" 1.5 gig DVD-ROM..
      One of the most interesting things that I've heard about both the X-Box and GameCube discs are that the way they are recorded, they start from the outside and go in, similar to vinyl LP's. Supposedly it was done to make load times faster, since most of the data is on the outer edge of the disc, where the read time is the fastest on an optical drive.

  7. Suffering at the hands of Compatibility by G0SP0DAR · · Score: 1

    This is an interesting idea. It certainly could not be a bad thing for such games as tic-tac-toe and mastermind and the like, maybe even sokoban ;), but but this high-level abstraction can cause limitations on things that demand the high performance inherent in state-of-the-art video games. ASM is king of the gaming domain, and I don't see that ever changing.

    --


    Calm down, it's *only* ones and zeroes.
    1. Re:Suffering at the hands of Compatibility by jonr · · Score: 2

      ASM is king of the gaming domain, and I don't see that ever changing.
      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 /. is sometimes mindboggling, people seem to be making facts up as fast as they can write First Post! J.

    2. Re:Suffering at the hands of Compatibility by Anonymous Coward · · Score: 0

      Important low level code requiring optimal speed is often written in assembler.

    3. Re:Suffering at the hands of Compatibility by Anonymous Coward · · Score: 0

      The correct term is not "assembler", though it's a common misuse. You want "assembly".

      One assembles assembly code with an assembler.

      And it's really not such a big deal any more. Most of the stuff that might have benefitted much from this, like blitting code, is encapsulated in SDL or DirectX. Also, a lot of stuff that used to be worthwhile to poke away at in assembly is now done in dedicated hardware.

    4. Re:Suffering at the hands of Compatibility by G0SP0DAR · · Score: 1

      Whoa, there. I'm not saying that all the best games are written in ASM, but are optimized for each specific processor. A number of great games were written in ASM, however (10 years ago at least!), but how many all-time favorites don't have ASM snippets in them? This whole platform-independence thing will never support those games at that level of performance.

      --


      Calm down, it's *only* ones and zeroes.
    5. Re:Suffering at the hands of Compatibility by Anonymous Coward · · Score: 0


      Alpha Centauri had a ton of hand-tuned intel assembler in it -- this was the reason that Loki couldn't get a PPC Linux version of it up.

      Most 3D flashy games don't need assembler, because the bottleneck is the 3D output -- which is handled by API calls. But 2D, computation intensive games certainly still use assembler to smooth the choke points out.

    6. Re:Suffering at the hands of Compatibility by Zeinfeld · · Score: 2
      ASM is king of the gaming domain, and I don't see that ever changing.

      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/
    7. Re:Suffering at the hands of Compatibility by Graspee_Leemoor · · Score: 2

      And a lot of GP3 was written in assembler, though we all know how buggy that turned out...

      graspee

  8. Already have that don't we? by Anonymous Coward · · Score: 0

    Well we already have that with Amiga Anywhere don't we.? Except with a smaller footprint and already out at the developers.

  9. this will never happen by bilbobuggins · · Score: 1

    this will never work because the console companies will all reject it. they make the majority of their money through proprietary games that make you want to buy the console.
    if square hadn't moved to sony would the playstation really have been successful? people bought the machine because you couldn't play FF on nintendo. from a business perspective, this is financial suicide.

    1. Re:this will never happen by S.O.B. · · Score: 1
      You're absolutely right. They make their money off the games but not because it's written for a specific console but because the profit margin is higher. Now wouldn't they jump at the chance to easily sell that game to someone using another console. Someone who wouldn't have bought it because they didn't have the hardware.

      By the way, if you read the article you would have seen Sony listed as one of those contributing to the project. I may not own a console but I hear Sony has sold a few of them.

      --
      Some of what I say is fact, some is conjecture, the rest I'm just blowing out my ass...you guess.
  10. but will they port it to the Amiga... by 56ker · · Score: 1

    one of my favourite platforms - but sadly programmed for very little these days.

    1. Re:but will they port it to the Amiga... by 0xB · · Score: 1

      The whole point is that they don't have to port it to the Amiga. The games are platform independent.

      Just download and install Java for your amiga and the latest Quake4 based game will look as good on your Amiga as it does on the newest and fastest multiprocessor PC. Well, nearly.

      --
      0xB
  11. This can only work for some games by Dr.+Bent · · Score: 5, Insightful

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

    1. Re:This can only work for some games by 0xB · · Score: 1

      Maybe not Quake, since one of id's goals is to push the limits of graphics technology.

      But the engine doesn't really have to 100% java. You can have an impure version of Sun's goal by having a the core of the game in Java with small portions in native code where performance matters.

      --
      0xB
    2. Re:This can only work for some games by Magila · · Score: 2

      That would negate the purpose for the whole thing, all the parts where speed matters are the parts that are hard to port.

    3. Re:This can only work for some games by 0xB · · Score: 1

      If you don't have to worry about porting the easy bits, then you've got more time for the hard bits.

      --
      0xB
    4. Re:This can only work for some games by 56ker · · Score: 1

      Isn't this just a cynical software developers dream of being able to write something that'll work on every platform without having to write any more code? Won't people's version of Java vary from machine to machine as well?

    5. Re:This can only work for some games by Alsee · · Score: 2

      Won't people's version of Java vary from machine to machine as well?

      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.

      -

      --
      - - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
    6. Re:This can only work for some games by bentini · · Score: 3, Insightful

      Exactly. This is why UNIX never caught on. There were certain parts (device drivers/platform dependent code) that couldn't be written in non-specific C. So even though a lot of the system code and applications were completely portable, the system never caught on and died a horrible death.
      This historical retrospective was brought to you by sarcasm.

    7. Re:This can only work for some games by icknay · · Score: 1

      Quake [X] will never be written in Java.

      I think it's going to be very hard for that prediction to stand up as the years pass. Partly it's the hardware getting faster, but a lot of it is the Hotspot/compile-on-the-fly technology getting better. At some point, Java is not interpreted at all. Java bytecode is just a distribution language -- by runtime it's compiled to native anyway.

    8. Re:This can only work for some games by Anonymous Coward · · Score: 0

      Also the fact that Java is a network-centric language, whereas with C, networking is a hack, and a real pain.

    9. Re:This can only work for some games by Pussy+Is+Money · · Score: 1, Flamebait

      The more advanced the "on-the-fly" technology, the more unpredictable delays you introduce, the longer your startup times become, and the more memory you use. It's wrong to think that better hardware will absorb those costs because it's not true.

      --
      Pushin' 'n dealin', shovin' 'n stealin'
    10. Re:This can only work for some games by zpengo · · Score: 2
      If the only types of games that Java can truly implement and make platform-independent are (relatively) slow, light on graphics, or "written for smaller segments of the market", is it really worthwhile to pursue this as some sort of holy grail?

      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?

      --


      Got Rhinos?
    11. Re:This can only work for some games by Unruly · · Score: 1
      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.


      Actually, quake 2 had a project going that used java (for it's security) check around planequake for it.
    12. Re:This can only work for some games by Dr.+Bent · · Score: 2, Insightful

      If the only types of games that Java can truly implement and make platform-independent are (relatively) slow, light on graphics, or "written for smaller segments of the market", is it really worthwhile to pursue this as some sort of holy grail?
      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).

    13. Re:This can only work for some games by Rinikusu · · Score: 1

      Personally, this is precisely why I decided a year or two ago to do my gaming projects completely in Java. My interests lie primarily in RolePlaying Game work (2D, sprite based, see SNES/NES style games), which does not need any real sort of performance. It's the story that matters (I hope). It would be nifty to have a game I can run on any system with a JVM, it just means more potential market.

      Granted, if I were doing an FPS, I'd probably not go Java, but then again, I know *nothing* about the performance of Java in that kind of environment.

      --
      If you were me, you'd be good lookin'. - six string samurai
    14. Re:This can only work for some games by codingOgre · · Score: 2, Informative

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

      --
      Space may be the final frontier, but it's made in a Hollywood basement. --Red Hot Chili Peppers, Californication
    15. Re:This can only work for some games by j3110 · · Score: 2

      I agree with most of your post, but I think there is a way for Quake X to be written in java. Using NMI and OpenGL, I think anyone could get acceptable results considering that my computer spends more time waiting on the video card than the code to execute. However, Sun will probably fix their shoddy, broken implementation to actually work right just for this purpose. Don't let anyone convince you that Java is slow at math! I forsee much better 3D support in Java's very near future. This is the second story in the past week or so about this kind of thing.
      Anyone serious about doing OpenGL (which is anyone serious about cross-platform 3D graphics) should visit NeHe Productions. 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 :)

      --
      Karma Clown
    16. Re:This can only work for some games by smallpaul · · 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?

    17. Re:This can only work for some games by Stormie · · 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 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.

    18. Re:This can only work for some games by Anonymous Coward · · Score: 0

      Glad to see Sun says 'Yes' with its retarded undefined thread behavior.

    19. Re:This can only work for some games by Anonymous Coward · · Score: 0

      You believe this because you don't understand the technical requirements of any of these games. Even the Sims would be horrible with Java. Just because it looks simple to some ignorant Java fudge-packer on Slashdot, doesn't mean it is.

    20. Re:This can only work for some games by Osty · · Score: 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.

      I disagree. It is just as easy to write poor code in Java as in any other language. In fact, I'd be inclined to suggest that Java actually hinders good design, with its fragile system of inheriting everything from Object. That's Bad Design (tm), and should be avoided. If you want to be able to use something like Java's native collection classes (lists, for example), you have to inherit from Object even if doing so runs against your design. Better to either use a dynamically typed language (for example, Smalltalk), or a language with generic programming constructs (templates in C++). A smaller set of limitations may be imposed (for instance, it may be required that the class implement some sort of comparison operator, for sorted lists), but that does away with requiring inheritance from Object. (what happens if/when Object changes? everything that inherits from Object will need a recompile, at the very least.)


      It may be "easier" to make a good design in Java than in C, but it's even easier if you use something like C++ and STL (caveat -- you need to know the language you're working with. If you're using C++, but treating it like C, it's going to be no better than C. Same for Java if you treat it like C++).

    21. Re:This can only work for some games by El_Nofx · · Score: 1

      I agree, If every console was to use some java as a base for every game and then just use a type of java VM for each platform that would just give Sun almost complete control over the console market. Then why would you need to buy the X-Box to play a certain game when you could play it on your old ps1 with crummier graphics.
      That would pretty much stifle innovation in the market and get rid of competition. Microsoft is going to be against it, Sony won't like it.

      With those guys on the other side of the ring the chances don't look very good.

      --
      It's not the OS it's the user that sucks. If it's user friendly, you get stupider people. - clinko
    22. Re:This can only work for some games by bay43270 · · Score: 3, Informative

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

      As a professional Java developer, I've learned not to give up on Sun. Java's potential has jumped leaps and bounds in the last few years.

    23. Re:This can only work for some games by bolthole · · Score: 1

      People are forgetting that when it comes to the "core bits that need to be written in ASM to be faster", it doesnt have to be either-or. You can have that routine originally written in java, and then load platform-specific optimized bits IF AVAILABLE.

      Kinda similar to the various quake display options:
      generic software rendering, generic OpenGL (if available), or [seriously tweaked for custom card version]

    24. Re:This can only work for some games by thomas.galvin · · Score: 1

      A smaller set of limitations may be imposed (for instance, it may be required that the class implement some sort of comparison operator, for sorted lists)

      So have them implement a common interface instead of inherit from a common base class? What does that gain you?

      I've never understood why people don't like having Object as a common ancestor to all objects. Being gaurenteed that things like toString() are always there is nice...

      I agree that the single inheritance model forces you into some tough design decisions, but as things stand, Object is your friend.

      (what happens if/when Object changes? everything that inherits from Object will need a recompile, at the very least.)

      What happens if/when the STL changes? What happens when one line out of 500 changes in a header file that all of your other files reference? Not to mention that most developers will be doing a nightly build anyway...make clean all is also your friend...I don't trust compiler chaches.

    25. Re:This can only work for some games by bonzoesc · · Score: 2, Informative

      1) FPS - runs slow on my 1.2G Thunderbird - no
      2) FPS - no other information
      3) Simulation - could be
      4) It's like #3 but without all the features - could be
      5) Business Sim - *wets pants in anticipation*
      6) Movie franchise - shit, if they can make a movie franchise game on 2600, they can do it in Java
      7) Simulation - probably
      8) Kiddie Simulation - probably
      9) Multiple games - dunno
      10) SWEET BLACK BABY JESUS WON'T THEY STOP MAKING THE SIMS EXPANSION PACKS - could be

    26. Re:This can only work for some games by mikec · · Score: 5, Interesting

      Think about this for a minute. Five years ago, I was running Quake on a machine about 1/40 the speed of the machine I'm using now, and Quake ran pretty well. Now assume that Java detractors are right and Java is only 1/2 as fast as C/C++. Why should it have trouble with Quake? Java runs many times faster on my current machine than carefully written C/C++ did on my machine five years ago.

    27. Re:This can only work for some games by Elevation · · Score: 2, Insightful

      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. 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. OpenGL could certainly have extensions added to facilitate any specific hardware requirements that a console might field. And the graphical effects programmer might have to reorder texture/model drawing and transfering commands for optimial performace, but this could certainly be done in either Java or C++.

      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.

    28. Re:This can only work for some games by Stormie · · 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..

    29. Re:This can only work for some games by Anonymous Coward · · Score: 0

      Why does everyone think that it has to be all Java if this does get implemented. When Java was first introduced, did we all stop writing code in all other languages....NO....What this could mean is that if you as a game developer are willing to accept performance loss (if there is any) for portabilty, then go ahead....

      All those in need of blazing frame rates can still use whatever they need (Assembly or whatever) do achieve their goals.

      All the platforms that wish to allow these games to run should just have support for JVMs and everyone can be happy.

    30. Re:This can only work for some games by EthSoma · · Score: 1
      Quake [X] will never be written in Java.

      Javalobby.com linked to this paper a few weeks ago that I think does a good job of addressing the performance issues in using java for game development. Here's one choice quote from John Carmack (page 75):

      "We are still working with significant chunks of an existing code base. If I did want to go off and start fresh, I would likely try doing almost everything in Java."

      --
      It is truely written: a man has five times as many fingers as ears, but only twice as many ears as noses.
    31. Re:This can only work for some games by kcbrown · · Score: 2
      Wow...those screenshots at the top of the main page of JavaGaming.org are incredibly lifelike! They have a photorealistic quality I've rarely seen in any game, much less ...

      ... er ...

      Oh, those aren't screenshots? Erm, never mind then. :-)

      --
      Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
    32. Re:This can only work for some games by Elevation · · Score: 1

      I am also a game programmer who has written both VU microcode for the PS2 AND vertex shaders for the PC and my assertion is that the while you can certainly expose some level of platform specific features to your graphics effects programmers via extensions to a graphics API, it would be a serious mistake to expose anything on the level of assembly, which is in essence what you are suggesting. Do you force the other programmers dealing using your graphics code to set registers and build DMA chains themselves using inline assembly? Or do you attempt to encapsulate those functions in a clean interface and advise limitations on rendering and texture transfer order. Even vertex shaders have their low-level functionality encapsulated in a clean and flexible API.

      I will bring up Criterion's Renderware yet again. Their system nearly completely encapsulates hardware functions, yet also exposes hardware specific features for the various consoles via extensions to the programming interface. Sure if you have a large in-house team that ONLY wants to develop for the PS2, you may have to create your own system from scratch if a system like Renderware doesn't support your wacky ideas for the IPU, but these are the rare exceptions. Take a look at the number and quality of titles Criterion's Renderware, you can get high performance out of cross-platform libraries.

    33. Re:This can only work for some games by collar · · Score: 1

      > Quake [X] will never be written in Java.

      I remember back when Quake 1 was released. I would have given you long odds that Quake 2 would be made for Windows 95. DOS was faster for running games, why have all the extra overhead of running windows?

      I was wrong.

      When WinQuake came out and id said they were only going to release games for windows I was shocked. Looking back on it it seems so logical, no more need for all those soundcard drivers and video card drivers in the game. The loss of speed turned out to be a non issue as computers advanced, what made a big difference on a pentium 120 didnt matter so much on a pentium 200.

      I'm not saying it's a definite, I just wouldn't write it off.

    34. Re:This can only work for some games by Heutchy · · Score: 1

      You do realize that DirectX 8 supports N-patches, quintic Bezier curves, and B-splines.

      Hey - look at this! We can now do these neat tricks without having to program an entire chip in assembly (at least vertex shaders abstract away most of the assembly)

    35. Re:This can only work for some games by Anonymous Coward · · Score: 0

      Carmack: ""We are still working with significant chunks of an existing code base. If I did want to go off and start fresh, I would likely try doing almost everything in Java."

      /me throws .Net book in the garbage, picks up Java book again.

    36. Re:This can only work for some games by tshak · · Score: 2

      Think about this for a minute.

      And if you give it two minutes, you come up with even more insight :-). Seriously, you make a good point. However, ask John Carmack what he thinks about not having access to memory. For example, there is an MSDN article (too lazy to look it up) showing how a simple graphic operation was over 50 times faster when using pointers in C# (in "unsafe" or "unmanaged" code). Of course, this was a very isolated test. The point is that even if Java or "Abstract Machine" based platforms are generally 50% slower, it doesn't mean that intense 3D applications will follow the same trend.

      Java, .NET, VB, Python, etc. are all designed to allow you to focus on the "problem domain" instead of the "plumbing". With 3D gaming, however, one of the major problem domains is the plumbing.

      --

      There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
    37. Re:This can only work for some games by Physics+Dude · · Score: 1

      Yes, the 1.4VM made HUGE advances for 2D and 3D performance. And is easily able to handle Quake type games. The demos at JavaOne were on 700MHz boxes with 256MB and they were generating a realtime flythough of the Grand Canyon 300+ MB data set at ~60FPS with full linear filtering, mapping, shading, etc!!! It was orders of magnitude faster than the 1.3VM.

      Don't knock it until you've seen it!

  12. Classic Arcade by inhalent · · Score: 1

    Maybe classic arcade games (Pacman, Ninteno I), but nothing anyone would ever want to pay money for... Especially if you have to go through the likes of Sun to get it.

  13. Pong by BrookHarty · · Score: 2

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

  14. This will never fly by DragonMagic · · Score: 2, Insightful

    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
    1. Re:This will never fly by bleckywelcky · · Score: 1


      I pretty much agree with what you're saying, but this may just push the development towards what sorts of features are included in each console. Maybe one console can hook up to the internet, allowing for multi-player capabilities. Maybe one console will hook up to a proprietary network while another console will hook up to a public netowork - perhaps the proprietary network console is cheaper, but you are hit with the subscription costs. Perhaps another console manipulates the game to fake a perceived 3D environment, while others don't.

      Since most revenue comes from the sales of the games anyhow, the whole indsutry could just shift. They could just move like the average computer user market has moved. Prolly 99% of the users work on an x86 architecture, where the competition is at how the x86 architecture is used. The development has just moved to lots of implementation/little design instead of little implementation/lots of design.

      Heck, if such a standard were to be implemented, perhaps we would now be seeing a lot more grass roots type games available.

    2. Re:This will never fly by Michael+Wardle · · Score: 3, Interesting
      I don't see how any of the game system manufacturers would approve of this.

      From the original article...

      My inbox is constantly full of e-mail from the participants in the experts groups just banging away on the specification because they understand its importance. So along with Sun, we have companies participating like Sony Computer Entertainment...


      It sounds like Sony (developer of the PS2) is interested after all. Perhaps it's for their games consoles, perhaps it's for their cell phones, perhaps it's all hype, but they do seem interested.

    3. Re:This will never fly by mgblst · · Score: 1

      So you mean i can just pop this CD into my cell phone and play the game??? Cool :)

    4. Re: This will never fly by Anonymous Coward · · Score: 0

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

      So basicly what you are saying is that, instead of having a ''monopoly'' on all the latest popular games via agreements with a handful of major game developing companies, they would actually have to produce the most optimal hardware at the lowest possible price to keep attracting customers?

      Well, now that I think it over, it would probably be best if we kept going with the current model...

      I mean, just because a company knows that people will continue to buy its products, regardless of their quality or value, just because they are the only ones that support the most popular software, doesn't mean they won't continue to strive to improve the quality and value of their products!

      Its not like they are going to stop focusing on improving the quality and value of their products, and start focusing on other things like I don't know maybe...

      *** Striving to make sure that the most popular software continues to only work on their systems, and relying on that as a revenue stream as opposed to product optimization. ***

      I mean it is not like we have ever seen this sort of thing before...

      Sorry, I couldn't resist :-)

    5. Re:This will never fly by thomas.galvin · · Score: 1

      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.

      You mean kind of like computers?

      The X-Box might as well be a PC. There is absolutly nothing stopping Sun from writing a java VM for X-Box, including it on a game disk, and dropping it on the hard drive. The playstation will get there. The console market has a very good chance of going the way of the desktop market...those who make compatible consoles will at least have a chance at profitability (think all the Wintel clones), those who do not will either find their nich (think Apple) or die.

      People like standards. Industry like proprietary. We outnumber them, and there is always someone waithing in the wings to give consumers what they want.

  15. Not unreasonable. by 0xB · · Score: 1


    Most modern games have a simple set of rules (aside : it seems to be a general rule that the simpler the rules, the more fun the game is), lots of creative work (artwork, level design, mission design, whatever) and an engine to tie it all together.

    Only the engine has to be ported to a platform - the rest is already independent.

    --
    0xB
  16. This is not worth it by GeorgieBoy · · Score: 2

    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.

    1. Re:This is not worth it by Anonymous Coward · · Score: 0

      OK, Flight Sims and FPS' may need a lot of native code, but those aren't the only games on the market.

      Look at lower-end strategy games (Civ3, not War3 of course, it's bleeding edge) or software toys (The Sims, SimGolf, etc) and you're talking about games that could conceivably be written for this platform.

      And don't fool yourself into thinking that only games pushing at hardware envelopes advance gaming. Good games, addictive games, simple games, are more commercially viable and get more enjoyment out of them than any bleeding edge title ever will.

    2. Re:This is not worth it by banky · · Score: 3, Insightful

      >So the idea of write once, run everywhere, of course requires that a set of gfx libs are implemented on every platform.

      Once upon a time, there was such a lib - OpenGL (and its free version, Mesa). However to counter this, a company (whose name you know) introduced a proprietary, platform-specfic graphics lib. It started off lame, and is now supposedly pretty decent. (This is how this company generally performs).

      Anyway, such options exist, but mindshare has gone away from them, in favor of convenience - who needs cross-platform apps on the desktop, when there is only one desktop of consequence, anyway?

      --
      ZOMG I WOULD LOVE TO KNOW ABOUT YOUR FEELINGS ON MACINTOSH VERSUS WINDOWS, VI VERSUS EMACS, AND HOW YOU'RE NOT A DORK
    3. Re:This is not worth it by SirRichardPumpaloaf · · Score: 1

      The console makers would work hard on porting the graphic libraries to their hardware, making them as fast and featureful as possible. Then all of the games would run better on their console than on their competitors'. The nice thing is that the libraries need only be written once, by the people who know the most about the hardware.

  17. Don't hold your breath... by telstar · · Score: 1
    "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."
    • Considering Microsoft makes the XBOX, and the long legal history that Sun and Microsoft share, I wouldn't count on this goal being satisfied now or ever.
  18. money by Ruliz+Galaxor · · Score: 1

    Bah... Sun just needs more money so they come up with this.
    Ok, ok, Java is platform independent, really nice, but I don't think you get the same performance with javagames in comparison to the way they are created nowadays.

    On top of that, I think MS will 'talk' to the developers of Xbox games to leave Java the way it is and not to create any Javagames at all.
    Let's stay realistic, Mr. Sun, Java may be great for some small games and webapplications and other crossplatformthingies, but 'large' games? Naahh... I think not.

  19. Fast language like C++? by TechnoLust · · Score: 2, Insightful

    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!"
    1. Re:Fast language like C++? by Anonymous Coward · · Score: 0

      Uh no.
      James Gosling, who has coded in C++, would never consider himself a C++ coder.
      He does C. The OO of Java is based on SmallTalk/Object-C and has NOTHING to do with C++, but a little bit of syntax. In fact, he was opposed to operater overloading and it took the team to get overloading of + for String cat.
      However, as to the speed, Java is simply a language that is normally compiled to a Virtual Machine. Now, they will simply convert from one machine to another.
      It will be fast.

    2. Re:Fast language like C++? by jjeff · · Score: 3, Interesting
      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.


      Now i like java its a very nice language (although i havent really done much with it yet).

      I still think its too slow. ive tried 1.2.x, 1.3.1 and 1.4 and i havent really noticed any performance improvements. - yes i can run any java program fine on my duron 900 at home with 512Megs ram but on my P 233 / 64MB laptop everything is dog slow.. even just javac Vehicles.java && java Vehicles takes at least 1 minute to spurt out text (in the console) about how many wheels each vehicle has.
      and trying to run something like jedit (this is a really nice program btw) is painful!

      now is there something wrong with my setup?
      because if not i dont see java as a viable language for writing games.(except maybe something like xscavenger).

      --
      when everything is working perfectly.. BREAK SOMETHING before something else FUCKS up!
    3. Re:Fast language like C++? by dead_penguin · · Score: 3

      ...even just javac Vehicles.java && java Vehicles takes at least 1 minute...

      The reason this is slow is not because Java is slow while it is running, but because there is a fairly heavy overhead associated with starting up the JVM. This is actually happening twice here; running javac actually requires the JVM to run. Once running, compiled java code runs at a speed in about the same ballpark as C or C++.

      Where java is dog-slow, however, is in its GUI libraries, especially Swing. I haven't had a chance to try this yet, but supposedly there were some improvements in Sun's recent 1.4 release. Other GUI libraries such as the one from IBM whose name just escaped me also are supposed to address these issues.

      Btw, anybody doing lots of compiles of java code and consistently swearing at the slowness of javac should try jikes. It's an open-source java compiler that runs as a native binary. Much faster than javac!

      --

      It's only software!
    4. Re:Fast language like C++? by Cebu · · Score: 1

      IBM's SWT developed by OTI would be the library you're thinking of.

    5. Re:Fast language like C++? by Anonymous Coward · · Score: 0

      I can attest to this (especially with mac os x). GUI stuff with java is dog slow, even with some expert coding it's less than fast. I don't see games ever being big with java, unless a VM is enabled hardware level. That's sort of contrary to the point of this article, since it's about hardware independance.
      But if most hardware had a VM chipset, and maybe a graphics especial, distibuting bytecode may be a good option...

    6. Re:Fast language like C++? by Anonymous Coward · · Score: 1, Interesting

      Smalltalk and Objective-C have late binding, dynamically dispatched object models.

      C++ and Java have early binding, static vtable based dispatch.

      Java's object model is a strict subset of C++'s, and has very little to do with Smalltalk's. It adds reflection, but it is done as a library, seperate form the language itself, but this could be added to C++ without changing the object model at all. In fact, you could do it (hackishly, and non-portably) without changing the compiler by using debugging info.

      You, and many others, have been mislead by Sun's marketing.

    7. Re:Fast language like C++? by Kamel+Jockey · · 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.

      --
      In case of fire, do not use elevator. Use water!
    8. Re:Fast language like C++? by Zenki · · Score: 1

      Get a newer version of the STL from dinkum. Contrary to popular belief, Microsoft doesn't implement the C++ libraries. The implementation is provided by dinkum, and their newest version for vc++ 6.0 is up to date with C++ standards.

    9. Re:Fast language like C++? by autopr0n · · Score: 2

      even just javac Vehicles.java && java Vehicles takes at least 1 minute to spurt out text (in the console)

      Well, duh. Load the JVM (a whole OS into itself), compile, close the JVM, load the JVM load your program and run it. Of course it's going to take a while. Imagine if you rebooted your Linux or Windows machine twice before running your program...

      --
      autopr0n is like, down and stuff.
    10. Re:Fast language like C++? by arkanes · · Score: 2
      Once running, compiled java code runs at a speed in about the same ballpark as C or C++.

      Erm, no. The general figure given is 20 times slower, although to an end user that's probably sufficent for most apps to "feel" the same speed.

    11. Re:Fast language like C++? by Iffy+Bonzoolie · · Score: 1

      There's a lot of new stuff in 1.4 that is specifically designed to allow for hardware acceleration of image/component rendering and whatnot. Look at java.awt.image.VolatileImage and go from there. It's beginning to have some DirectX-like capabilities.

      -If

      --
      Run a pencil-and-paper RPG campaign with your far-off friends: Gametable!
    12. Re:Fast language like C++? by Anonymous Coward · · Score: 0

      Wow man - get a clue! 20% slower is more like the accepted average... and that's not necesaarily adjusting your programming style appropriately to take advantage of Java's strengths.

  20. Source code? by cies · · Score: 1

    So will I be able to see the source code of the game?

  21. Java too slow! by ktulu1115 · · Score: 1

    This idea will never work... Java is extremely slow compared to languages such as C++. Remember Java is an intrepreted language, not compiled in the strictest sense. Not only that, the platforms are too differientated to be able to make this a viable solution. It would take forever to develop such a platform.

    --
    # fuser -v /dev/attention | grep work
    #
    1. Re:Java too slow! by Anonymous Coward · · Score: 0

      Java is extremely slow compared to languages such as C++

      Wrong.

      Remember Java is an intrepreted language, not compiled in the strictest sense.

      Wrong. Java can be compiled to native machine code.

      Not only that, the platforms are too differientated to be able to make this a viable
      solution.


      Wrong. Tell it to the people who developed OpenGL.

      Well, you're 0 for 3.

    2. Re:Java too slow! by ktulu1115 · · Score: 1

      I hate to say it but you're wrong for the first and last points. Write code that does the same thing in C++ and Java and see which is faster. For most applications, I guarantee C will beat it. As for OpenGL.. as far as I know that was all on the PC platform. They didn't port OpenGL to a console system. Even if they did, OpenGL is *only* a graphics library, not a complete API for the whole OS/system. Big difference.

      --
      # fuser -v /dev/attention | grep work
      #
    3. Re:Java too slow! by Mithrandir · · Score: 2
      *yawn*. One more clueless idiot that speaks without any actual knowledge. In some cases, Java runs faster than native code, in other cases, about the same. Got search google for performance comparisons. Go read the article where they talk about the games available today that have just as good framerates as anything written in C/C++. And, if you'd even had any more of a clue, you might do a history search on this site.


      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
    4. Re:Java too slow! by bolthole · · Score: 1
      They didn't port OpenGL to a console system.

      Actually, I believe linux-for-PS2 has an OpenGL implementation that ships with it.

    5. Re:Java too slow! by Graspee_Leemoor · · Score: 2

      "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

    6. Re:Java too slow! by Anonymous Coward · · Score: 0

      Java runs slowly because of garbage collection, not because it isn't native code. If you take a look at the comparison linked here a couple weeks ago, you'll see that the performance of JDK 1.4 is about on par with the performance of JET which compiles java to native code. The reason they're both slower than C is because they both implement garbage collection.

    7. Re:Java too slow! by Mithrandir · · Score: 1

      Not wistful thinking at all. For the past 2 years or so, using the Hotspot-based VMs, most of my code has been running faster than the equivalent native code applications. This is not GUI stuff (SWING sucks), but server-based code doing number crunching, file format translations, and plenty of other stuff. It takes a little while for the dynamic compilation to analyse the code and build the appropriate structures, but on a long-lived server application, that's really trivial amount of time. Take a dig for the HP paper mentioned where they do the same thing with native code running inside a VM. Even there they claim a 20-30% improvement of already compiled native code. Don't just blindly believe stuff you've been taught in the past. VM technology is superior to standard systems and only going to get better.

      --
      Life is complete only for brief intervals in between toys or projects -- John Dalton
    8. Re:Java too slow! by Graspee_Leemoor · · Score: 2

      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

    9. Re:Java too slow! by Mithrandir · · Score: 1

      No, I didn't miss your point at all - you're not reading what I said. HP have a series of research papers where they run native code in its own VM and that code runs 20-30% faster than running native code straight on the CPU with no VM. PA-RISC/x86 ASM, whatever, is no different to Java bytecode. They are all just considered intermediate formats for the VM. That's how my Java code runs as faster, if not faster than traditional native code today, using today's JVMs such as hotspot.

      --
      Life is complete only for brief intervals in between toys or projects -- John Dalton
  22. Java is Slow by Daveman692 · · Score: 1

    A lot of the time Java seems slower than other languages. Also games won't look the same on each box. No longer would companies be competing for hardware and sw but just hardware which I doubt they would go for.

  23. Re:Why TWM stomps all over KDE 3.0 by Anonymous Coward · · Score: 0

    $twm

    twm: another window manager is already running on screen 0?
    twm: unable to find any unmanaged screens

  24. JavaGamming is a good idea ... by Anonymous Coward · · Score: 0

    Just because this could just ease the design of multiplatform tools and games....

    Java2D for instance is one great things that can be just cool for many interfaces !

    Just imagine that as XStuff is Wintel based, the adaptation for J2RE are quite forward!
    About the J2RE on PS2, Sony have said it was done and bundles with the linux dev-toolkit (cf. previous /. posts) but no assumption can be made of J2RE redistribution licese models ;-)

    Anyway, this is great news! Who start to build a Tetris Arena using Java2D ?

    Imagine PC users Xstuff, PS2, Mac ... fighting together ... using a single game ...

    One darkside, is the Java3D lack for gaming profile, i mean, Java3D is powerfull (much more that both OpenGL and directX or Starbase ..) but it is also much more slow due to some design choice. Sun's target Java3D to be clean pure object for design tools or stuffs but not for full blasting imediate rendering ... So, i do think it is time to influde a FAST_IMEDIATE_RENDERING scheme in Java3D !

    Let it be the first to post the JSR ;)

    An other great stuff is to have WebStart ready on the next console so people will have nice cross-platforms applications ready to use ...

    4R34'.

  25. Read the article... by SaturnTim · · Score: 4, Interesting

    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. Re:Read the article... by Anonymous Coward · · Score: 0
      Games like Escape Velocy Nova [ambrosiasw.com]that are Very popular

      For what value of "Very popular"? I'm an avid gamer, on multiple platforms. Never heard of that game or Ambrosia software.

    2. Re:Read the article... by Anonymous Coward · · Score: 0

      elegid = alleged?

    3. Re:Read the article... by Cuthalion · · Score: 1

      You haven't heard of Ambrosia? They're the good people that brought us Apeiron and Maelstrom. If you don't recognize those, then you need to put more skill points into Mac Gaming.

      --
      Trees can't go dancing
      So do them a big favor
      Pretend dancing stinks!
    4. Re:Read the article... by Aapje · · Score: 2

      I regularly hear about people that have moved from a Mac to a PC, but can't do without EV. They spend a lot of effort to get it to run on a Mac-emulator. The game is easily expandible and great plug-ins have been created. I believe that the EV series (EV, EV Override and EV Nova) are among the most popular games on the Mac.

      PS. I have amused many of my nephews and nieces with Ambrosia's games. I could even get some of them to ask their parents for a Mac ;)

      --

      The Drowned and the Saved - Primo Levi
    5. Re:Read the article... by Guppy06 · · Score: 2

      "what games actually use 100% of the hardware they are running on?"

      When you're talking console games, quite a few. Especially as you near the end of the life cycle. This is one of the big differences between consoles and PCs.

      PCs suffer from a vicious bloatware cycle, where hardware performance increases one week and software size increases the next (compare the latest version of MS Word to an old copy of WordPerfect 5). These increases constantly feed each other so that it's rare to find a PC fully utilized by a program.

      Consoles on the other hand have their hardwares' lives artificially extended by their manufacturers, mostly by their proprietary hardware formats. Software publishers can't go all out as they can on the PCs because the consoles' hardware imposes a limit that will be around for 5-7 years.

      As the life cycle of a console reaches its end, publishers are quite close to the limits imposed by the hardware and are usually looking for tiny little ways to tweak their software to get just a little more performance out. Compare Final Fantasy VII to Final Fantasy IX. Super Mario 64 to Zelda: Ocarina of Time. Heck, at times it can be difficult to believe that Super Mario Bros. 1 and 3 are both for the same system.

  26. it could happen... by Anonymous Coward · · Score: 0

    java, as it is now, isnt cut out for gaming... however, if there were to be a pretty extensive API (or whatever, i cant remember the name... DirectX is an example) created, then it could happen... it would have to be some pretty genious programming

    i remember back when visual basic wasnt cut out to program squat in games... then M$ released DirectX7, and it worked with VB... a whole slew of unique games resulted from some independent game programmers (inverted dreams, close approach, DDCK: myth of creation (original homepage is down), and some really cool 3d engines whose names escape me right now :(, just to name a few)... now im not saying VB is the most powerful language to program 3d games in, but it just goes to show that a lot is possible with good programmers and the right API...

  27. Action games are not all there is by pkaminsk · · Score: 1

    All the comments I've seen so far tend towards "Java is too slow", "it can't take advantage of custom hardware", "it won't push the cutting edge", etc. This may well be true for action games, but that still leaves a lot of other genres -- strategy, wargame, adventure, RPG, puzzle, etc.

    For example, don't you think that Civ3 would've come off nicely in Java? The upcoming MOO3? Perhaps even Tropico? (OK, I'm showing my strategy bias, but I'm sure you can think of other examples.) Not all games need to take advantage of cutting-edge technology to be fun. This point has been made so often on Slashdot, you'd think people would remember this cliche by now.

    And finally, I would've expected all Linux (game-loving) zealots to be cheering for this technology. It might actually bring some real games to their forsaken OS.

    1. Re:Action games are not all there is by Anonymous Coward · · Score: 0

      >For example, don't you think that Civ3 would've come off nicely in Java?

      Try playing Civ3 on a really large map with 16 civs. There are plenty of people on Apolyton who claim to have >5 minute turns in the middle ages using pretty decent hardware. Just waiting for the computer between turns is not much fun. Besides, not everyone think Java is easier than C++. I know I am not the only one who finds C++ easier to use because of destructors, templates, and no need to constantly type cast because the Java containers all use Object.

    2. Re:Action games are not all there is by NSParadox · · Score: 1
      Actually, Civ3 runs like crap as it is.


      Imagine it being 10x slower in Java. Yech.

      --
      Unless mankind redesigns itself .... robots will take over our world. (Stephen Hawking)
    3. Re:Action games are not all there is by Mr.Sharpy · · Score: 1

      While it is true that there are other game genres beyond action games, any programming platform MUST be able to work in all the genres. Otherwise, you will be producing consoles that only play the genres you mentioned. Do you really think anyone will buy a console that cannot play all their favorite sports/action games? If you are proposing that action games remain in a proprietary language specific to a certain console's technology, well that totally disqualifies the argument for a universal java game development language. Not only would you have to learn the langauge for a specific machine, but also the java language.

    4. Re:Action games are not all there is by ktulu1115 · · Score: 1

      I somewhat agree... some game platforms it *might* work for. However anyone who disagrees with the fact Java is too slow for a real-time fps doesn't know sh*t about programming.

      Who knows... if this does end up working maybe it will create a new genre of games.

      --
      # fuser -v /dev/attention | grep work
      #
  28. Hee hee hee... by Anonymous Coward · · Score: 0

    ASM?

    *laughs*

    Where have you been for the last, I don't know, 10 years?

    *laughs some more*

    Jeeeesus.

    1. Re:Hee hee hee... by Anonymous Coward · · Score: 0

      Some games written in the last 10 years do, in fact, have assembly code. (Well, mostly c/c++ with little bits of assembly.)

      Some games come to mind. Quake and Quake2. Yes it is a short list.

      Jeeesus.

      Don't bother replying if you're going to say that the original poster meant games were written entirely in assembly.

    2. Re:Hee hee hee... by G0SP0DAR · · Score: 1

      Thanks for thinking before replying!

      --


      Calm down, it's *only* ones and zeroes.
  29. Java's Crossplatform Shortcomings by mgrochmal · · Score: 2, Insightful
    A cross-platform compatibility would be great. However, it would have several hurdles to overcome before it accepts widespread use.

    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 .sig Intentionally Left Blank.
    1. Re:Java's Crossplatform Shortcomings by bolthole · · Score: 1
      Industry Support - XP's omission of a native Java RTE shows that not all developers are willing to go with Sun's development software.

      Err, no, it just shows that microsoft wants to kill java.

  30. Believe it or not, Java is improving by i_am_nitrogen · · Score: 2

    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.

    1. Re:Believe it or not, Java is improving by Anonymous Coward · · Score: 0


      Umm, are you joking?

      LimeWire is a huge, unweildy, blob.

      Run LimeWire for a few days. Then run gtk-gnutella (or Gnucleus, or whatever native client you prefer) for a few days. Then try and say that 'it's getting close' with a straight face.

      LimeWire is nowhere near the performance of native code. LimeWire's main advantage, other than being perfectly cross platform, is the network that LimeWire has built up for itself. Thier caching servers are a godsend to Gnutella. The *only* reason to use LimeWire over a native implementation, is that there's no native Linux client that can do simultanious downloads of the same file from multiple hosts. But if you can live without that, there is zero reason to run it.

    2. Re:Believe it or not, Java is improving by radish · · 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 :)

      --

      ---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"

    3. Re:Believe it or not, Java is improving by Anonymous Coward · · Score: 0

      Absolutely no problem. All we have to do is port Linux to Java. :)

  31. Just the beggining by Leknor · · Score: 1

    I like the idea. I understand an accept that it will suck at first but that is how things are. It takes time to make these things good. Do you remember how horrible the 1.0 JVMs were? It may take 10 years but I'm glad sun is putting the ball in motion so to speak.

  32. Get Real! by quakeaddict · · Score: 2

    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.
    1. Re:Get Real! by LadyLucky · · Score: 3, Informative
      Swing is a bad example. It runs slow even when compiled to native code (in fact, a bit slower). The problem isnt the java, the problem is the inherent design of swing in which you are very deep in inheritance trees, much abstraction going on.

      An example of why java guis dont need to be slow is eclipse. You can't tell its written in java (except maybe the slow load time :-)), but this uses a a different windowing toolkit.

      In summary, the VM adds overhead, yes. But the VM is not the cause of a lousy GUI toolkit.

      --
      dominionrd.blogspot.com - Restaurants on
    2. Re:Get Real! by Sloppy · · 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?

      Yes, I honestly think so. I even think that someday, you will play a FPS written in some high-level scripting language like perl/Python/Ruby, and it will be so fast that won't even notice. CPUs are getting ludicously fast.

      The real reason we might not see Java gaming, is that things might move so fast that it gets skipped over.

      --
      As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
  33. Not a good idea? by Pengunea · · Score: 1

    As a longtime gamer I don't think this is a good idea. While clever and interesting some things key to the successs of games seems to have been overlooked.

    Basic console and hardware differences have caused video game deveolopers to make games that suit the console's specs. While this can hold back the full potential of some games it causes uniqueness in the games themselves. Sacrificing something due to a weaker area causes developers to work harder in another area. Removing the console difference would cause the very contingency that causes games to be so different from console to console.

    While a console created for 3D rendering (ie: N64) can display sprite graphics on games like Paper Mario it won't handle a game like Jojo's Bizzare Adventure (PSX) as well. So there's a kind of Bleem! situation going on. To accomidate for a system that isn't set up specifically to play a certain range of games you've got to use the easiest to emulate games limiting your game selection greatly.

    Plus I'm not sure if Java could pull it off at all. Pardon my disbelief.

    --
    Starkle, starkle, little twink.
  34. There already is a Java game by theJavaMan · · Score: 0
    and it's working, and it's fast and it's great.


    IL2 Sturmovik.


    If you look at the dlls of the game, they are full of JNI calls. for example: Java_com_maddox_opengl_GLContext_CreateWin32


    OpenGL call...


    Java_com_maddox_rts_JoyFF_Stop


    Joystick call.


    all of those are system dependent calls which require performance. all the rest is done in java
    (Game logic, AI , mission editor, interface)


    there you go, a real world example...

  35. Java Hardware by hotchai · · Score: 1

    All the comments so far have mentioned that Java for games will never take off because Java is slow. Yes Java is slow because it is interpreted by a JVM that runs on top of the native platform. But what if Sun could convince console makers to embed a MAJC-like chip in their boxes? Sun already has the technology -- check out the specifications of the MAJC architecture embedded into their latest framebuffers (XVR-100).

  36. GameSpy not impartial by pkaminsk · · Score: 1

    Do you wonder why GameSpy's article described the technology in such glowing terms? They're a member of the Java Game Profile JSR's Expert Group. Hardly an impartial observer; they should've at least mentioned their involvement in the article.

  37. Oh yeah... by Anonymous Coward · · Score: 0

    Nothing like games that break the "Slooooooow" barrier.

  38. Bungee did it 2.5 years earlier by Mastagunna · · Score: 1

    If Microsoft did not buy bungee, we would have played it, and be done with it by now.

  39. What about Chu Chu Rocket? by scubacuda · · Score: 1

    That was a very SIMPLE, but FUN game for Sony Dreamcast!

  40. Link to Sun's Java gaming effort. by Anonymous Coward · · Score: 0
  41. great, but.. by laserweasel · · Score: 1

    As an Apple fan I of course applaud this, as the reason why I also own an AMD/Nvidia beast is purely due to our lousy game selection. The downside? Well, there is one and it's a killer. What's going to happen to video games if they're developed for all platforms at once? The biggest market for games is obviously console buyers. PC enthusiasts are less in number from the headcounts I've seen and PC game piracy is beyond rampant. If all video games are developed with console players more in mind than PCs we may lose our PC Baldur's Gates and wind up with Console Baldur's Gates.. Dramatic example, maybe, but it's worth considering.

    --
    ["Marge, I agree with you - in theory. In theory, communism works. In theory." - Homer]
  42. SDL is half way there by FrostedWheat · · Score: 1

    SDL is a great way of making games that run on different platforms!!

    I know this is aiming at "One binary for them all" and that, but I'm sure a more open-source friendly alternative could be built under SDL.

    Just a thought :)

  43. Whoa whoa! Stop the "portability" train! by Theo+DeRaadt · · Score: 1
    Every time I see someone call Java "portable," I just shake my head in wonderment that anyone could be that ignorant.

    Sure, Sun Microsystems would like you to believe that Java is the ultimate in cross-platfrom portability, but could you list all the platforms that the latest JDK runs on? Hmm... let's see...

    • Windows
    • Mac OS
    • Linux
    • FreeBSD (maybe one of these days...)
    Don't see OpenBSD in there, do you? Or NetBSD, the king of so-called "portability" (the irony is stinging). Furthermore, Java can't even perform as well as C or even C++. How do they expect to use this to write games for consoles that already have limited resources?

    It is apparent that the only clear choice for game development is still well-written C. It's fast, clean and, if well-written, far more portable than Java could ever hope to be.

    Thank you.

    --

    --
    Theo DeRaadt
    Founder, OpenBSD project.
  44. Not a chance by Chris+Canfield · · Score: 1
    There is no way this is possible. Gaming has evolved into Hollywood extravaganza at its brightest, with all of the special effects that entails. Java is a platform that introduces a processor-taxing virtual layer of representation that would be intolerably slow for an industry where each company banks its future on having a higher poly count than their competitors. Eidos is very proud of the fact that the new Laura Croft has 5,000 polys, making even more realistic her unrealistic curves. While this kind of unrealism is quite common amongst Sun's press releases, the likelyhood of Java being successful as a gaming meta platform on the PS2 is about as likely as the CDI coming back from the grave: Zero. And what are the chances of the next GTA 3 or MGS 2 coming on a platform that pretends the idiosyncracies of the hardware doesn't exist?

    Sun makes it very clear that either A: they don't understand this or B: they're pretending it isn't important.

    Using Java technology's cross platform capability, developers are creating new game and entertainment experiences that fully leverage the network and allow the player to engage anytime on multiple devices.

    They are? How interesting... Might you point to one? Or are you talking about the browser-based games on Yahoo?

    Sun shows an image of people playing linked games on a cell phone, a Palmpilot, a gameboy advance, and a flipped picture of a PS2 controller. Some of these devices actually have network connections widely available (a place where utilizing java would make sense), but they aren't the ones that are used for gaming. The Gameboy advance, for example, would be impossible to design and develop a decent game for if you didn't know that you had to choose between 16 million colors, or a 256 color pallete with 0, 1, or 2 scalable / rotatable backgrounds and 4, 2, 0 tiled backgrounds, your available sprite count, your audio options... And not only that, but you would never be able to put in a CD to that cartridge based thing anyway. In all of these examples, the end user would have to buy a copy of the game specific to the device, a move that would make sense for the console creators who only survive by taking a cut of every game sold that has been enabled to work on that hardware. Binary cross platform compatibility would be suicide for Sony/Microsoft/Nintendo to support.

    The Sun representative talks about how you could fiddle with your inventory in Everquest or chat with your friends while you are away from your computer. Thankfully, most internet-enabled cell phones are already equipped with many options for chatting with friends, and reorganizing your inventory is about as much fun as it sounds. This has already been tried, with Sega's VMU and Sony's Pocketstation, with very limited success (though Sega gets Kudos for true research).

    Sun mentions that You don't know Jack, Majestic, and Who wants to be a Millionaire, as well as the scripting in V:TM all utilized Java. Jack and Millionaire are all simple, browser based quiz shows with a reliance upon audio and clever dialog. Majestic is audio and text based in a revolutionary but not processor-intensive way. V:TM may have its events scripted in java (using java as a scripting language rather than a programming one), but by no means is any substantial portion of the code java based.

    I've said it before and I'll say it again: I really wish large companies would get a little respect for the business side of the gaming industry and do their homework before charging right in to foolish and doomed projects that will only waste their money and developers' time.

    [Quietly steps down from soapbox and wipes froth from mouth]

    --
    This Sig is a mnemonic device designed to allow you to recognize this author in the future.
  45. The acronym says it all by Christopher+H · · Score: 1

    Too many Java games are PIGs already.

  46. They don't need to... by Anonymous Coward · · Score: 0
    AmigaAnywhere is an initiative to get Amiga code running on pretty much anything - phones, PC's, PDAs, thin clients. I'd use this over Java any day for developing multi-platform games. They have already got deals (of some kind) with Nokia to get this into set top boxes.

    Let's face it, Java sucks for anything that needs performance. Why not try a new(er) multi-platform OS...

    1. Re:They don't need to... by amix · · Score: 2, Informative

      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?
  47. Re:Whoa whoa! Stop the "portability" train! by Anonymous Coward · · Score: 0
    hey, an intelligent troll and a tempered one!


    you sir should be in a zoo inside a cage

  48. One rhetorical question. by suso · · Score: 1, Troll

    What does Sun know about games?

    1. Re:One rhetorical question. by LPetrazickis · · Score: 1

      Would you like to play a game of thermonuclear war?

      --
      Is this a sigs-optional kind of place? 'Cause I am totally down with that if you know what I mean.
    2. Re:One rhetorical question. by Ozric · · Score: 1

      What does SUN know about anything. Java ?

    3. Re:One rhetorical question. by Ziviyr · · Score: 1

      Would you like to play a game of thermonuclear war?

      Only if its on a global scale and runs on both modern consoles through Java. :-)

      --

      Someone set us up the bomb, so shine we are!
  49. So I'll use Linux to play games? Not! by Anonymous Coward · · Score: 0

    Maybe I could use my evil M$ partition or Linux to play the same game, but given the fact that Java applications run much slower under Linux compared to M$, I'd still go for M$.

    So, I won't still be able to remove all of these crappy FAT partitions from my HD...

  50. Re:Whoa whoa! Stop the "portability" train! by Anomolous+Cow+Herd · · Score: 1
    you sir should be in a zoo inside a cage

    Well, Mr. DeRaadt would certainly make a better physical specimen than most of the Slashdot community, what with his active lifestyle and passion for mountain biking. With Slashdotters on the other hand, well, pretty much all the evidence you need is in the latest poll.

    --

    "I don't know that atheists should be considered citizens, nor should they be considered patriots." - George Bush
  51. ugh, yes, it will never play the newest games... by Anonymous Coward · · Score: 0

    let me sum up the comments i see...

    blah blah blah
    java is too slow
    blah blah blah
    tetris/pong would be okay
    blah blah blah
    maybe simple RTS games, or mario
    blah blah blah

    gee, will computers get faster? (hint, the answer starts with a 'Y') Do you think maybe the JVM interpreters will get faster, or move to embedded chips? (psst, same answer as the first one)

    Java games will never be as good as the best ASM-built graphics feast of the day, but maybe the benefits of developing once for many platforms will outweigh that cost.

    In 10 years it will probably be easy to run RTCW on any machine, if you can find a way to make it run on your current OS.

  52. WTF? I thought Java solved the X-platform issue.. by Beatlebum · · Score: 1

    LOL. Java has failed to deliver as a X-platform development system yet Sun thinks it can succeed in the gaming space? Excuse me, but hasn't history shown us that no matter how fast the underlying hardware gets, developers are still unwilling to trade performance for abstraction. I'm sorry, but when it comes to gaming, users want every bit of horse power they can for their $. These are the guys that buy a new video card every 6 months to get a few extra frames per second; they don't give a monkey's chuff whether the same game runs on a different platform, they care about speed, resolution and pretty textures.

    When will those bitches at Sun learn?

  53. Now isn't that interesting by dknight · · Score: 1

    Well now, it seems I submitted an ask slashdot bringing up the question of this very topic not long ago. It was, of course, rejected, but I find it interesting nonetheless.. Seems someone else had that same idea as myself.

  54. Possible, but Very Unlikely... by shadowcabbit · · Score: 1

    Yes, it is possible to allow cross-platform gaming with a platform-independent language such as Java, even on consoles. This could be done by way of a special, natively-compiled virtual machine that is platform-specific and installed on a console's hard drive. Think of DirectX-- basically a new API. It would require a patch to the console's boot loader (to allow it to recognize the Java-disc as a playable game disc), but that doesn't seem terribly difficult.
    However... I do not expect this to happen for quite some time, and I do not expect it to go over well at all with graphics-whores because of the "lowest-common-denominator" factor. Already people boast that their computers' Voodoo Eleventy-Billion cards with 4 GB of DDR RAM and HDTV-out look better than the XBox or PS2. Imagine if you couldn't get the most performance out of your PC video card because the game has to be playable on the other platforms. Additionally, ports are big business. Max Payne being on three different setups surely didn't hurt 3D Realms' pocketbooks (even if I personally despised the game), and the more money a company can soak from you, the better.

    --
    "Why Subscribe?" Good question...
  55. Missing 2 things by banky · · Score: 2

    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
    1. Re:Missing 2 things by Anonymous Coward · · Score: 0

      Hmm... Don't mean to be pedantic, but:

      The size of the console market of games is an order of magnitude larger than the PC games market.

      PC gaming IS the niche, not the norm.

      So you can be sure that the lions share of games programmers worldwide are not "Windows+DirectX only"... Just the PC games programmers, which, like I said are a niche.

      This is why Loki and the likes failed: They tried to develop a niche market in a niche market.

  56. Won't be easy to catch on... by Junior+J.+Junior+III · · Score: 2

    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!
  57. Like to marry your boss? by software_non_olet · · Score: 1

    What might be good for business solutions is not neccessaryly acceptable at home. Or else all the games would be written in COBOL.

    Sun is still dreaming it's Java dream and at the same time putting down the Open Source Software development. Looks like Sun is in desperate search for market share and money but without any new idea in stock.

  58. Java is improving by ajiva · · Score: 1

    Java 3D performance *is* improving, check out the J2SE Experts Booth at JavaOne, where we will demo a 3D application running at 90% of the C++ application using the NIO to load textures into video memory. Its impressive, and the Java application is 2000 lines versus the C++ nearly 5000 lines!

    1. Re:Java is improving by Mithrandir · · Score: 2

      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
    2. Re:Java is improving by ajiva · · Score: 1

      Go download JDK1.4, JDK1.3 *beta* is old, ancient. Besides having a ton of bug fixes, performance is up big time.

  59. The interview is absurd, but I'll bite by Flavio · · Score: 1, Troll

    First off,

    "There are a lot of misconceptions about Java," explains Melissinos, "one is that it's too slow".

    Ok, let's suppose for a minute that Java is _not_ slow and that this guy's correct. Then we see the following:

    Game developers would say, 'You'll never get C code to run as fast as Assembly, you'll never do it.' Well it happened. When C++ came out, the same thing occurred, and once again C++ became the development standard. The same thing holds true today, folks are saying there is no way Java is as fast as C++. Well I'm here to show you it can and it can even run faster."

    I find it impossible to believe that a bytecode program, which runs on top of a VM (written, by the way, in C++ or in an equivalent imperative language) could be faster than C++ unless the programmer is absolutely clueless. But I'll even be satisfied with "only 50% slower" if I see an example.

    What I won't take is reading the previous two and the following in the same damn article:

    "Developers are saying that it's so much easier to code in Java than in C++," says Melissinos, "and there is less to worry about as well. The Java code actually takes care of problems like garbage collection and memory issues that C++ doesn't. In C++ you have to do all that manually and Java does it automatically saving so much time in development."

    So we basically have this guy saying that Java can be faster than C++, which can be as fast as assembly and still admitting that Java uses garbage collection (an inherently slow task). He's either so passionate about Java that he doesn't realise what he's saying or he's been spending too much time with the people in marketing.

    1. Re:The interview is absurd, but I'll bite by thammoud · · Score: 0

      >>I find it impossible to believe that a bytecode program, which runs on top of a VM (written, by the way, in C++ or in an equivalent imperative language) could be faster than C++ unless the programmer is absolutely clueless. But I'll even be satisfied with "only 50% slower" if I see an example.

      The Java VM is written in C.

      There are many assemblers out there written in C, C++ and Pascal yet the production language is faster. What is your point ?

      >>So we basically have this guy saying that Java can be faster than C++, which can be as fast as assembly and still admitting that Java uses garbage collection (an inherently slow task).

      For C++ garbage collection and the benefits of GC in systems, I suggest that you read:

      GC issues

    2. Re:The interview is absurd, but I'll bite by BlueGecko · · Score: 2

      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.

    3. Re:The interview is absurd, but I'll bite by Flavio · · Score: 1

      > There are many assemblers out there written in C, C++ and Pascal yet the production language is faster. What is your point ?

      First, an assembler and a VM are two very different programs. An assembler can be written in BASIC and produce faster code than an assembler written in C. A VM written in BASIC will NOT run your bytecode faster than a VM written in C.

      What's _your_ point? You've just shown to be ignorant regarding a very simple concept.

      Second, I never said GC didn't have any benefits and I specially don't need you to give me a link to a primer to GC.

      I simply claimed there's no way a language that's compiled into bytecode and has GC will be as fast as regular C++ as it's claimed in the article. Don't turn this into a Java vs. C++ contest and specially think before you post.

    4. Re:The interview is absurd, but I'll bite by Anonymous Coward · · Score: 1, Informative

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

      Here's how this happens. The JIT, usually hotspot, organizes a table of functions and likely memory demands, and stripes this in memory to fit the cache size for the processor. This sort of information is not available in a static analysis (e.g., like with gpp, or even javac for that matter). Instead, it learns this by running the code. Then, the JIT arranges this so that cache lines are kept local during execution. The time to access a cache hit is about 3 ns; the time to flush a cache and fetch an instruction buffer is like 100ns, mor or less. (Yea, this varies alot, but it's like several orders of magnitude or at least one order of magnitude.)

      So that's how Java can be faster than C++. The trick is, however, that the program has to be run long enough to create a learning curve. And there are some pathological programs that don't have a regular pattern of instruction and memory use. But most do have a pattern, and Java leverages that. C++ is limited to static analysis, which (because of the halting problem) can't predict with much accuracy what portions of a program will be associated with which portions of memory. (Plus, memory is dependent on what else is running when the program is loaded, etc., etc.)

      Now, if you just took a simple program like sorting, well, hell, C++ blows Java away. But if you have a complex program that runs for a good while, then Java matches or even beats out C++ and even C. It's all about the cache.

    5. Re:The interview is absurd, but I'll bite by thammoud · · Score: 0

      >>I simply claimed there's no way a language that's compiled into bytecode and has GC will be as fast as regular C++ as it's claimed in the article

      Compiled into byte code but recompiled into machine code on the fly based on program behavior are completely different things. GC's do help. I will be more than happy to point you to a GC pand dynamic code optimization primers because you really need to brush up on you technical skills and knowledge. Never say no way.

    6. Re:The interview is absurd, but I'll bite by Flavio · · Score: 1

      > Now, if you just took a simple program like sorting, well, hell, C++ blows Java away. But if you have a complex program that runs for a good while, then Java matches or even beats out C++ and even C. It's all about the cache.

      Can you direct me to (non-trivial) code that demonstrates this? I'd like to experiment with it, because it seems really neat.

    7. Re:The interview is absurd, but I'll bite by Anonymous Coward · · Score: 0

      Too many people say java is slow but seem to forget that most jvms have features such as hotspot etc which compile frequently used classes into native code. If you dont even know of simple features such as hotspot & keep refering to java being interpreted... u have no right to comment. Another thing most people forget is that most games etc spend most of the cpu time involved w/ gfx generation. If tehse key features contained native code then the core features of the game such as AI could remain as java. Suns dream would then be achieved.

  60. Wrong by Goonie · · Score: 2

    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?)
    1. Re:Wrong by horse · · Score: 1

      A lot of what current games do is talk to the graphics card (via Direct 3D or whatever). That's all done through libraries.

      If the Java 3D libraries (which can be and probably are written in C) are fast enough, Java might be adequate for many games.

      There will always be games that push the edge of performance and require more. Most games don't (think Civ 3, or Warcraft, or even Everquest).

      I could see Java working for games if they get the libraries right. Time to market is just as important for games as other products, and Java has significant time-to-market advantages over C++.

    2. Re:Wrong by Anonymous Coward · · Score: 0

      You're right Goonie. Java is just too damn slow because of all the bloat. Just look at Id's VM code for Q3A... it was designed to compile to multiple platforms (like java) and yes it worked, but it really sucked because of all the interpretive bloat. Nobody uses the VM for Q3 anymore... they compile straight dll because it's faster and tweaked to a particular OS. In fact, many mod auths will compile straight to dll over multiple platforms just to satisfy speed issues. I can see why Sun would want to use this as a selling feature, but the proof is in the pudding.

  61. Java may be viable even in 3D gaming by Anonymous Coward · · Score: 0

    Check out this URL for more specific info http://www.fullsail.com/fs1/news/current/scoop_ca. html

    It seems that even full 3D games may be possible.
    Java has become faster and more optimised in the last couple of releases , so it may be a alternative for easy cross-platform gaming.

  62. kick ass by autopr0n · · Score: 2

    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.
    1. Re:kick ass by Anonymous Coward · · Score: 0

      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.

      You may be right - Java probably is the best language for dong 'real' game programming, but I'd rather play games without male nudity, thanks.

    2. Re:kick ass by Anonymous Coward · · Score: 0

      > Java is a sweet programming language. I can't stand C++.

      Let the computer graphics industry take note that some dork does not like C++, therefore, all games must not be written in this language because he only learned Java in school.

      > java will be a viable option for dong 'real' game programming.

      Using the JPRE? (Java Penis Rendering Extension).

      Can't the dongs in the games you play be rendered quick enough in C?

  63. Riiiight... by AltaMannen · · Score: 1

    So how exactly would I be able to program PS2 Vector Unit Processor code in Java? Does Java Gaming profile have any inline assembler macros or something?

    1. Re:Riiiight... by Anonymous Coward · · Score: 0

      So how exactly would I be able to program PS2 Vector Unit Processor code in Java?
      That was my first thought as well. Java Games == lowest common denominator == 1975 PONG. Okay, maybe I am a bit too hard on Java - let's say "Dig Dug."

    2. Re:Riiiight... by Anonymous Coward · · Score: 0

      I don't think you would have to as java is an abstraction layer over the machine. You program to java, and not worry about vector units, the jvm should handle that.

  64. Does anyone else see the irony.. by xtal · · Score: 1, Troll

    That the article posted before this one is the most outrageous vendor lie ever told? *grin*

    "Write once, run anywhere (maybe)"

    Steve

    --
    ..don't panic
  65. there just trying to potty train java by Anonymous Coward · · Score: 0

    they need some legitimate games and they know it.
    still 2 yrs. off. still too slow. oh someday it won't even matter. the slowest code will work for gaming. It the games that need improvement not the code

  66. Yeah right! by Anonymous Coward · · Score: 0

    Java? For games? How many real-life games that you see written in Java? And I don't mean that stupid, slow loading piece of garbage you load on browsers.

    And to make it cross-platform? Hahahahah.... you must be joking!

  67. 3D speed is the key... by NightWhistler · · Score: 1

    Actually, this just may work... think about it:

    1) The REALLY hard work in games is mostly 3D calculation these days...

    2) Java Virtual Machines rely on the underlying OS to do all the gruntwork

    Combining these two facts it makes sense to implement the 3D API for the Java virtual machine using the underlying system's own 3D API (OpenGL on Linux, Direct3D on Windows, etc).
    AFAIK this is already the case with Java 3D. By using this stratigy all the hard work is done by fast, platform-dependant code, while the game retains a nice abstraction that works on any platform. Add all the advantages of Java to this (solid software, shorter developement time) and it might not be such a bad idea at all...

    DISCLAIMER: If this doesn't make sense: I'm drunk. ;-)

    --
    PageTurner Reader: open-source e-reader for Android with cloudsync. http://pageturner-reader.org
  68. Re:Whoa whoa! Stop the "portability" train! by XBL · · Score: 2

    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 ;-)

  69. Sun should fix what's broken first by mmusn · · Score: 1
    While basic Java runs fairly well across platforms, once you start getting into issues like audio, images, video, window management, drag-and-drop, etc., Java fails to work well cross-platform in my experience. Even something as simple as Forte-for-Java's window placement fails in annoying ways on Linux. Java3D is eclipsed by third party OpenGL bindings. Sun seems to try to make all their libraries work on Windows, but on MacOS and Linux, it's hit-and-miss. Sun has also been promising for years, but so far not delivered, support necessary to write computationally intensive programs, such as value classes and multidimensional arrays.

    Given this history, I don't have much confidence that Sun will deliver a toolkit that is truly useful for writing games across platforms. It looks to me Sun is getting side tracked with some sort of Microsoft-envy and neglecting the fundamentals of delivering a high-performance, cross-platform system. In fact, I think if they fixed their technical and license problems, other people would likely do a much better job at defining gaming APIs for Java than Sun ever could.

  70. this is stupid by Anonymous Coward · · Score: 0

    because software-hardware compatibility is only part of the problem. the f-ing media that xbox, playstation, and gamecube use aren't interchangeable.

  71. Possible, If History Repeats by Spencerian · · Score: 5, Interesting

    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.
    1. Re:Possible, If History Repeats by antistuff · · Score: 1

      Why not just write a native version of your video game player for each platform, this will help performace even more.

    2. Re:Possible, If History Repeats by smart.id · · Score: 1

      Because then you PROBABLY can't have 1 CD for every platform.

      --
      blog & fiction: jd87
    3. Re:Possible, If History Repeats by Anonymous Coward · · Score: 0


      Code takes up very, very little space. I doubt there's enough *code* in, say, Q3A to take up more than a few floppies.

      The reason we need CDs and DVDs today is for media (sounds, models, etc). Media is portable by nature.

    4. Re:Possible, If History Repeats by Graymalkin · · Score: 2

      Actually people like Capcom and Konami have been doing this for a while. Their arcade boxes ran pretty select hardware for specific games which is one of the reasons arcade machines are so fucking expensive and the console versions of the games don't look quite the same. The games are almost always run inside of an emulator on the console which makes it cheaper to port games to consoles. Rather than rewiritng all games to specific console hardware they only have to write a snappy emulator for the console to run the game inside of. The SNES didn't have half the components that the SF2 arcade boxes had in them but Capcom made a really badass emulator that took advantage of what the SNES DID have. What Sun wants to do with Java and game consoles is extend that concept to a more general virtual machine than an emulator.

      --
      I'm a loner Dottie, a Rebel.
  72. Alex St. John by Hunterdvs · · Score: 1

    Wildtangent anyone? Some of the stuff coming out of there is incredible.
    http://www.google.com/search?q=cache:RK-i9FqbijAC: www.wildtangent.com/+wildtangent&hl=en

    Christmas Dancer :) Anyways, if anyone has proved that this can be done on any kind of reasonable level, they have. Betty Bad
    http://www.wildtangent.com/playbetty.html
    it isn't Castle Wolfenstein but it's hardly pacman

  73. Consoles stay the same speed!!!!!! by AltaMannen · · Score: 1

    The article was about game consoles that exist today. Your arguments that PCs get faster doesn't hold for those platforms.

  74. OT: Re:Why bother? by AnalogBoy · · Score: 0, Troll
    "I don't know that atheists should be considered citizens, nor should they be considered patriots." - George Bush


    I don't know that idiots shouldn't be considered citizens, but i do know they shouldn't be considered for president. I wonder what George Jr's stand on this is. I guess he'll have to call his father to find out.

  75. Could be feasible by Anonymous Coward · · Score: 0

    I'm seing a lot of skepticism here, but I think that this could stand a chance (not taking into account the need for support from console makers). My main gaming machine is a P2-266 with a GeForce 256 SDR. It can still play most modern games. I DO play RtCW on it. I recognize that Java does have an overhead, but that overhead isn't too large. Anyone with a 500MHz machine or so should be able to play most modern games under Java. If they used a thin layer over an already multiplatform API, like OpenGL for 3D, it would reduce the overhead significantly.

    Or I could be completely wrong and everything I just said was BS.

    I personally would like to see this happen, as it would be nice to be able to play more games in Linux.

  76. Validates my Plan by madstork2000 · · Score: 1

    I was telling my brotherr who is an artist for Midway Games, that this approach would be a great way to write and distribute games. Though my plan was to use linux as the platform independent OS rather than java.

    My thoguhts were a bootable CD/DVD that contained the OS and the game, it could also have basic apps that a user might want to use during a game (like aim/icq/email word processor to keep a log/journal in, etc).

    My thought was that game developers could use a base Linux spec for this common to most all platforms. They could use their own proprietary stuff in the games. The users could then choose to return to windows when the games was over (ala old DOS mode stuff) or stay and work is the Linux environment.

    To me it would be a great way to get linux and OSS to the masses, though for every problem it solved it probably creates two, but regardless sony's plan sounded familiar.

  77. What about other issues? by Anonymous Coward · · Score: 0

    Java is decompilable by nature.
    How are gaming developers going to protect their hard work, when even with the best obfusciator on the market, a java jock with a days spare time on their hands can decompile their prize 3d gaming engine and distribute the source...

  78. java3d enables this on some platforms by nostriluu · · Score: 1
    I am suprised no one else has mentioned this, but Java3D, which is available on Windows, Linux, and Solaris (as well as, I think, Irix and some BSDs), enables native accelerated 3D rendering so you could do 3D visuals with decent performance. It is built on top of OpenGL or DirectX (your choice of either on Windows). There have been some pretty impressive demos for it, and it's pretty easy to code with.



    J2SE1.4, without Java3D, now supports features such as accessing the video card's memory directly (last I saw, for NVidia chips only).



    A 3D Java product wouldn't compete with the most optimized platform dependant code but it'd be good enough for something that was more dependant on reaching all the major platforms than it was on the most leading edge graphics. Though I guess I'm in the minority by thinking a competitive product wouldn't require the most leading edge graphics, I could see something taking off with that kind of cross platform support, 'specially once all the consoles have a net connection...

  79. Why this won't work by sbergman2 · · Score: 1

    I must say I was excited about this for a few minutes. But then I got the usual reminder that this won't work. Forget speed. Forget "Write once. Debug everywhere". The problem is more basic than that. You can be reminded of this too:

    1. Get the latest mozilla. (0.9.9)

    (You know, the one that's been refined to perfection over the last 4 years)

    2. It doesn't come with Java so search around on the net and hunt down the latest official Sun Java2 plugin. (Make sure and use the official Sun plugin so that when everything crashes and burns, you can't blame it on a third party.)

    3. Click on the "releasing" hyperlink in this story:

    http://www.gamespy.com/gdc2002/jgp/

    If your browser has not already died, click on one of the pictures on the left and then on the "back" link. Your browser is surely dead by now.

    Restart Mozilla, disable Java and note how much better things work.

    All hail Java!!!

    1. Re:Why this won't work by sloanster · · Score: 1

      hmm, sounds like a troll - and not even a skillful one.

      I just went there - no problem...

      Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020324

  80. Christ I hope not.... by Anonymous Coward · · Score: 0

    Given the fact that java more than lives up to the best definition of cross-platform, namely "works equally badly on all platforms," I hope to god that this never comes to pass.

  81. The guy is a salesdroid by Goonie · · Score: 2
    He's either so passionate about Java that he doesn't realise what he's saying or he's been spending too much time with the people in marketing.

    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?)
    1. Re:The guy is a salesdroid by Flavio · · Score: 1

      We had a chance to sit down and chat with the man in charge of this initiative, Chris Melissinos, chief gaming officer for Sun Microsystems, as he was preparing for his GDC presentation.

      That doesn't mean he's a marketroid. If he is, we shouldn't be wasting our time with him.

  82. Re:Whoa whoa! Stop the "portability" train! by Flarners · · Score: 1

    Hey fuckhead, you can run the Linux JDK using OpenBSD's binary compatibility. HTH.

    --
    "The problem with the French is that they don't have a word for 'entrepeneur'." -George W. Bush
  83. Java is slow as a dog on Windows machines... by ZipperHead99 · · Score: 0

    So am I now going to need a Linux partition to play games?

    Wouldn't that be funny.

    1. Re:Java is slow as a dog on Windows machines... by WetCat · · Score: 1

      Ha! Do you think it's quicker on anything else?
      My P3-1GGz run java same as my P-155 run basic programs...

    2. Re:Java is slow as a dog on Windows machines... by sloanster · · Score: 1

      Not sure what's funny, but it's not likely.

      I find gaming on Linux quite satisfactory - as it turns out, the games I like (q3a, RtCW) run on Linux, and run quite well.

      but never fear, you'll still be able to play games on your windoze pee cee....

  84. An academic argument. by Bitsy+Boffin · · Score: 2, Insightful

    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
  85. Would kill the video game industry... by miyax · · Score: 1

    ...wouldn't it?

    Sure, the games themselves would sell, but now there'd be no reason to spend $300 on the newest Playstation, or $200 on the newest Nintendo system. Sony would still do fine (after all they do make pratcially everything under the sun ^_^) but this would kill a company like Nintendo...who's principle business is in hardware.

    It's like what would happen if Apple ported OSX to x86. Great idea, yeah (hell I'd love it), and while Apple would make money off it, they'd lose *even more money than they'd make* on hardware--which generates more revenue for them than software does.

    Like Nintendo. (Can't base your business strategy on Pokemon and GameBoys, folks.)

    Nintendo would be gone...Sega's already gone...this would kill an entire facet of video game-play...Console Wars.

    1. Re:Would kill the video game industry... by stipe42 · · Score: 1

      The parent is a completely inaccurate depiction of the modern video game industry. All game companies sell their hardware at a relatively steep loss. They make their money on selling the license to develop games for their hardware.

      If Java or a similar technology allowed software to be run cross platform, then two things would most likely happen. First, hardware prices would increase because the game companies would need to make a profit on them since licensing won't work with open specifications and toolkits. Second, game prices would drop because of the removal of two major associated costs: porting and license fees.

      The increase in hardware prices and drop in software prices would probably balance out overall and the only real effect noticed by the consumer would be a greater variety of available games for their chosen console.

      stipe42

  86. Shouldn't this just be a comment.. by Roogna · · Score: 1

    in the previous article about vendor lies? ;)

    Roogna

  87. Can hear it already by The+Cat · · Score: 5, Insightful

    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.

    1. Re:Can hear it already by nathanm · · Score: 2
      The retail box model is horribly broken and will likely never be fixed.
      I agree. That's why this story about Valve's new "content delivery system" got me excited. New ideas like this that embrace the internet and cut out the middle-man are the future.

      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 & DMCA need to be repealed; and the SSSCA (now CBDTPA, or whatever it's called this week) needs to be killed before it makes it out of comittee.
    2. Re:Can hear it already by Anonymous Coward · · Score: 0

      Tell that to the consumers of these products that DEMANDS more effects, fps and whatnot. There is nothing wrong with the industry, they're simply selling what people want. Except for you and me.

      You and me, we are The Chosen Ones. We are destined to rule the world. Exceptional talent and true companionship makes us the greatest duo in this era of A New Age. With heroic effort and sharp wit, we will best all those who make crappy games. Come join us fellow Slasdotters! To the walls!

  88. Re:GameSpy not impartial - MOD UP by Anonymous Coward · · Score: 0

    good point!

  89. Still using Dos? by NanoGator · · Score: 2

    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."
    1. Re:Still using Dos? by bakes · · Score: 2

      I don't know of any at all. I should have added a sarcasm tag to be previous comment :-)

      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.

      --
      Ho! Haha! Guard! Turn! Parry! Dodge! Spin! Ha! Thrust!
    2. Re:Still using Dos? by brainiak · · Score: 1

      I was just playing Stunts on 2k. It works fine... unless you want sound...

      --
      You fix it.
  90. from the pigs-might-fly-department by PaganRitual · · Score: 1

    this is excellent, its great news ... i have been trying to find a low cost way to play all the endless stream of crappy sports games, boring puzzlers, no-brainer platform games, and samey beat-em ups on all the consoles for years ... and whats better, is that because its all written in java, each and every game will become turn based ... itll give me all the time i need to be able to click on the opponents fighter, select "heavy kick" from the drop down menu, and then click "submit" ...

    ... just someone get finished on an x-box emulator and be done with it ... i wanna play halo!!!

    1. Re:from the pigs-might-fly-department by Graspee_Leemoor · · Score: 2

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

    2. Re:from the pigs-might-fly-department by PaganRitual · · Score: 1

      yeah, and who wants to play FPSs on a console anyway??? all the controllers are fucking useless for them ... i would say that i would never buy a console for a FPS game, but i DID buy a N64 just to play Goldeneye ... if it doesnt come out for PC, just ill just wait for DNF, or Thief2, or Deus Ex2, or Quake4, or Doom3 (and GTA3)... M$ can think that they are gonna force PC gamers to buy their PC-in-a-box just to play a certain game or two ... but they picked the wrong year to try it in ... assuming at least a couple of those games make their release dates ... and dont forget about Prey (i know it sounds like a joke, but apparently they are continuing work on it AHAHAHAHAHA ...)

  91. Avionics by Pussy+Is+Money · · Score: 1
    When Charles Lindbergh had to build a plane to cross the Atlantic, he decided to build a plane with just a single, big fat engine. He won. His competitors, using expensive four-engine designs, either died trying or barely escaped with their lives.

    Intuitively, extra engines add extra safety to a plane. In practice, it does not work that way. Similarly, Java affords a programmer extra safety, as well as some convenience. But again, in practice, it does not work that way.

    What Lindbergh realized was, that when you add an engine to a plane, it means you need more fuel. But that means you need more room for fuel. Which means your plane gets bigger and heavier, which means you need another engine, if you want to maintain your safety margin. But that means more fuel, and this goes on forever until you shout "stop!" and begin the delicate balancing act of finding a sweet spots somewhere in this mess. Which is difficult -- although it's not anywhere near as difficult as it was in Lindbergh's time.

    In programming, it is still very difficult. And Java is nowhere near the sweet spot. In fact, for this particular application, i.e. gaming, it is so far removed from the sweet spot, that you have to start asking yourselves, "why bother with all these engines and the balancing act? why not just build a single reliable engine instead?".

    For example, Java advocates like to point to the fact that buffer overflows in Java cannot happen. What they really mean is that Java will not allow you to reference out of bounds array elements. Of course what they really mean by that is that it is very difficult to exploit these kinds of errors to execute malicious code (which sort of boils down to the rather empty truth that Java is not C, but that aside). But guys. Hello? Referencing non-existing array elements is a critical error. Whether it happens in Java or C, your program will crash and burn and take all non-persistent state with it. The only benefit Java offers here is that at least it protects the underlying system, but what kind of benefit is that, if the Java software is supposed to control, well, let's say, a plane engine?

    In other words, what the argument fails to recognize is that the true value is created in the top layer, and when that layer (i.e. your application) fails, that is when the real damage occurs. Protecting the lower layers is fine and necessary and dandy, but in most cases, the lower layers are not where the value is. And when it comes to the point that you program defensively against your own code, i.e. stop trusting yourself and rely on the machine to resolve the conflicts, that is when you have begun adding engines and fuselage and engines and more fuselage. There's very few people who can get it right and they take an awful lot of time to do it.

    --
    Pushin' 'n dealin', shovin' 'n stealin'
  92. Problem. by Decimal · · Score: 2

    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
    1. Re:Problem. by Ziviyr · · Score: 1

      (Q is a GameCube clone by Panasonic that can play DVDs. It is unlikely, however, that it will ever be sold outside of Japan.)

      And its unlikely the hardware is capable of reading games from DVD into the gamecube mainboard in the really nil-ish chance a game is ever put on one.

      --

      Someone set us up the bomb, so shine we are!
  93. What about Ultra HLE? Interesting implementation. by NanoGator · · Score: 2

    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."
  94. Two words: MAME ROMs by Anonymous Coward · · Score: 0

    You can play the same ROM set using MAME, the Multiple Arcade Machine Emulator, no matter which platform you're using; versions of MAME exist for Windows, Windows CE, Mac, *nix, OS/2, BeOS, three types of Amiga OS and even some handheld devices using Digita OS, EPOC32 or a Nokia 9210 cell phone.

    If I were programming a twitch reflex game these days, I'd use the design to write an arcade game and then release the ROM set I'd written for use with MAME, then watch it get used on about two dozen different platforms. Plus I've got my very own one-of-a-kind arcade machine too :-)

    1. Re:Two words: MAME ROMs by Anonymous Coward · · Score: 0

      Moderators- read this carefully. It's a very very good point....

  95. This will not likely happen. by LordZardoz · · Score: 2

    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

    1. Re:This will not likely happen. by Ziviyr · · Score: 1

      A PS2 has no relation to any sort of other existing hardwrare.

      Umm, actualy it bears alot of resembalance to the PSX. So much so that it inherits many flaws and the entire game library of the older system.

      Oh, the PSX exists, I almost forgot. :-)

      --

      Someone set us up the bomb, so shine we are!
  96. Check This Out by Enonu · · Score: 5, Informative
    This API absolutely rules: GL4Java

    It works on Linux, Sun, and Win32, and it hauls ass to boot! Quake3 in Java? It's definitely possible!.

    1. Re:Check This Out by Phlog · · Score: 1

      I sure hope it's capable of more than their screenshots suggest.

      Honestly, these screenshots make this it look like it's almost on the level of MacPaint or KidPix..

    2. Re:Check This Out by tof20 · · Score: 1

      Arkanae, which uses the opale.soya librairie which in turn uses GL4java , is a good example. At home, with linux, 1280x1204 windowed, 45 fps ! With a geforce2mx400, duron 600. I find it quite correct even for quakelikes !

    3. Re:Check This Out by wurp · · Score: 2

      Why not use the higher level API that Sun is developing for you, Java3D? We're using it for Magicosm, and FullSail uses it for a 3d racing game and a MortalCombat style game. All work very smoothly and quickly; you would never know it was Java unless told.

  97. Could this potentially kill the Game Industry? by NanoGator · · Score: 2

    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."
  98. Sun is doing it the hard way by ghillie · · Score: 1

    Or iSun has a different agenda. If the goal was to allow people to be abple to play games on anyones systems by supplying a CD, they should create a bootable system on a CD. A bootable linux on CD system is an excellent platform. Make one for Macs, and one for PCs. The games could be programmed in any language. But Sun is probably trying to promote java.

  99. Sun is Delusional by Anonymous Coward · · Score: 0

    If they're serious about this, I'm seriously worried about Sun's long term viability as an independent company. How much money did they loose last year?

    In my opinion the likelyhood that Sun will succeed with Java for games is about as likely as the day that all /.'ers would vote for Hillary Rosen as the president of the USA.

    Memo to Scott McNealy:
    Keep your eye on the ball your business. Stop bashing your competition, and for once actually focus on making your business profitable for its own sake.

  100. WTF? Troll? by Anonymous Coward · · Score: 0

    Anyone who knows anything about the topic at hand can see this is a legitimate comment and NOT a troll.

    Some idiot just thought "oh, he's dissing Java by saying it's not a perfect language!" and modded it down.

    No natural rule forbids the people at Sun from saying stupid things from time to time, you know.

    *sigh*

  101. Re:Whoa whoa! Stop the "portability" train! by Anonymous Coward · · Score: 0

    and you are the reason for openbsd's rampant popularity I assume?

  102. Sure enough by WildBeast · · Score: 2

    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.

    1. Re:Sure enough by Graspee_Leemoor · · Score: 2

      "While we're still waiting for the Java OS"

      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

  103. DVD, DVD, and DVD by yerricde · · Score: 1

    Each console, (X-box, ps2, game cube) USE A DIFFERENT FORMAT AND MEDIA TYPES

    PS2, Xbox, GCN, and PC all use formats based on DVD tech modulo minor differences, but they look in different places for the boot sector. Put the VM where each console will look for it, and then put the game itself in a standard 8cm DVD-based format. None of the current consoles are slotloading, and even then, it's easy to come by an 8cm to 12cm adapter for play on a future slotloading console.

    --
    Will I retire or break 10K?
  104. the game companies won't go for this... by Anonymous Coward · · Score: 0

    ...because it would mean that games couldn't take advantage of the strenghts of each machine, and instead would have to shoot for the 'average' machine. So why should a player spend $300 for a super-duper console, when Joe's Playa can run the same game?

  105. CPU-bound and IO-bound by yerricde · · Score: 1

    The more advanced the "on-the-fly" technology, the more unpredictable delays you introduce, the longer your startup times become

    Not if you recompile Java bytecode in one thread and load your game media in another. It's called overlapping CPU-bound and IO-bound processes.

    and the more memory you use.

    Memory is cheap.

    --
    Will I retire or break 10K?
    1. Re:CPU-bound and IO-bound by Pussy+Is+Money · · Score: 1
      Not if you recompile Java bytecode in one thread and load your game media in another. It's called overlapping CPU-bound and IO-bound processes.
      You can't just arbitrarily pick a point in the life of a program and say "this is where I start counting", and then at some arbitrary later point say, "see, it got faster". Before you even get to the point where you can load your game media, you will have to initialize the virtual machine, verify the bytecode, and initialize all the libraries. Then the memory you squander has to be collected later, and you don't count that cost either. So I'm not sure what you are trying to accomplish by sounding authoritive on a subject you are not even trying to address.
      Memory is cheap.
      That does not mean it does not need to be managed, and it does not help that Java's memory management model is naive, primitive and limiting.

      1. To my best knowledge, Sun's JVM never returns free memory to the OS[1]. If you have an interactive application, and you suddenly need a lot of memory (e.g. the user opens a large file), then this memory will be lost for the program's lifetime. While there are ways to ensure that the heap never grows beyond a certain point, this comes at the cost of making your program crash if it needs more memory (even though the operating system has plenty of memory available to it). I figured that with the long overdue death of Classic MacOS we had seen the last of this kind of stick-figure memory management. I was wrong.

      2. Memory is cheap, but garbage collection can make it expensive. Garbage collecting C allocators such as Boehm's can waste something like 70% of the allocated memory and Java is not much better. Moreover, because Java renders the process of garbage collection completely opaque, there is very little (read that as very little implicit and zero explicit) information that the programmer can feed to the allocator to make it more efficient. Did they even meaningfully spec System.gc() yet?

      [1] I've never seen it return memory on Linux and Sun. On Windows it is a little bit better, and you actually get a few commandline switches (nothing you can change at runtime for obvious but stupid reasons) that affect the allocator's behaviour in ill-defined ways.

      --
      Pushin' 'n dealin', shovin' 'n stealin'
    2. Re:CPU-bound and IO-bound by Jeremi · · Score: 2
      To my best knowledge, Sun's JVM never returns free memory to the OS[1]


      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.
    3. Re:CPU-bound and IO-bound by Pussy+Is+Money · · Score: 1

      No, I'm pointing to a design flaw in Sun's implementation and saying that it is a design flaw in Sun's implementation. But, if you want me to turn this into a Java flame, yes, it is a implementation flaw that was inspired by a fundamental design flaw in the Java language, namely the lack of a "delete" operator. That aside, considering that Sun is the one proposing "Java for games", I think it makes sense to examine their track record delivering an efficient Java platform is not very good.

      --
      Pushin' 'n dealin', shovin' 'n stealin'
  106. HOoey by Ranma · · Score: 1

    It is highly unlikeley that we will ever see this happening. They say that eventually you will be able to bring the disk to your friends house, blah blah blah, play it on any system. You know what that means for the game company? Less money! If John Doe can play the game anywhere, he only buys 1 disk, as opposed to 2 to play on the new console of the month.

  107. Dynamically Recompiled Apps+VM *could* be fast by edwinolson · · 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.

    1. Re:Dynamically Recompiled Apps+VM *could* be fast by Anonymous Coward · · Score: 0

      The funny thing is that this is very similar to what Microsoft is doing with .NET executables. Applications are compiled to native executable code at runtime with optimizations based on the current hardware -- although that is still a far cry from true dynamic runtime optimization.

      Would be nice though to see stuff like that worm its way into Java.

  108. Better idea by GrEp · · Score: 2

    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
  109. Java is too slow for games by Anonymous Coward · · Score: 0

    Civ3 could not use Java because Java is garbage ...collected. The GC pause would kill the interactivity of the game.

  110. Id's Camerack (spelling?) count CPU cycles by Anonymous Coward · · Score: 0

    He would have no use for Java whatsoever. Intel gave him big $$$ to make the Pentium IV shine by tweaking the machine op codes. Java can't be tweaked in the same way without rewriting the VM or calling native methods - defeating the point of using Java.

  111. Check this out by AKAImBatman · · Score: 3, Informative

    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.

  112. This sounds familiar by Entropy_ah · · Score: 3, Interesting

    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
  113. Re:Whoa whoa! Stop the "portability" train! by Anonymous Coward · · Score: 0
    It is apparent that the only clear choice for game development is still well-written C. It's fast, clean and, if well-written, far more portable than Java could ever hope to be.

    Good gracious, this is a major over-simplification of the situation. Sure, C is possibly the most widely supported general purpose language. But of course C by itself is far from a complete solution for game development.

    For a start, you would need to add a 3D graphics engine. Perhaps I can assume OpenGL for this. Then sound, networking, input. After adding these things, how good would C portability be? (I'm asking because I don't know.)

    Ok, I'm sceptical about Sun's claims too. But hey, if 3D graphics is the most processor intensive part of games, and if this new Java thing does a good job of 3D, well I don't know.

    Anyway, I'm not sure what Sun's actual scope is. They mention EverQuest, and multi-player Internet games. Maybe Sun can do well in this little niche. My flatmates play Dark Ages of Camelot heaps, and complain when the servers go down for updates. Maybe Java could make this kind of process less painful for someone?

  114. Old News!!! Checkout www.tao-group.com by ziperle · · Score: 1
    A leader in this field is Tao Group http://www.tao-group.com

    Amiga, Inc. (http://www.amiga.com) has partnered with Tao Group to deliver on platform independant multimedia. Doesn't look like Amiga plans to repeat history by producing a custom hardware and OS again.

    About Amiga:

    Amiga Inc. established itself in 1985 as the premier provider of multi-media technologies to the world. Today Amiga continues leading the way in multi-media by providing language independent technologies to developers for writing and porting applications to a new multi-media platform that is hardware agnostic. Amiga Anywhere, powered with intent(TM) from the Tao Group, enables applications to run unchanged on a broad range of processors including ARM, StrongARM, Intel X-Scale, OMAP, MIPS, Intel x86, Motorola 68K and Hitachi SH. It can run hosted on a wide variety of operating systems including Windows CE .NET, Windows 9x, 2000, Windows XP, Linux, and Embedded Linux. AmigaDE Player and applications can be purchased at the Amiga-Anywhere Website. Amiga is based in Snoqualmie, WA, and has offices worldwide. Amiga can be reached at (425) 396-5660 or visit the Amiga Corporate Website.

    1. Re:Old News!!! Checkout www.tao-group.com by Ziviyr · · Score: 1

      Amiga, Inc. (http://www.amiga.com) has partnered with Tao Group to deliver on platform independant multimedia. Doesn't look like Amiga plans to repeat history by producing a custom hardware and OS again.

      Yup, that is old news. Same way Amiga's lack of memory protection is old news.

      I liked the idea of using the QNX kernel, that was Amiga. This is TIMMY!!!

      --

      Someone set us up the bomb, so shine we are!
  115. Resource HOG? by fmaxwell · · Score: 1

    How dare you laugh at Project PIG (Platform Independent Gaming)?

  116. The 'G' language is the future of game coding by steveoc · · Score: 0, Offtopic

    The fantastic new 'G' language is the future of game coding.

    'G' runs at speeds comparable to hand-coded assembler.

    According to developers, 'G' is heaps easier to use than Java, since it does
    not require native methods, and the documentation makes no mention of garbage
    collection.

    Here are some examples of complete games written in 'G' :

    ----------------
    Quake clone -

    File: quakeClone.g
    program main (arguments) {

    Game myGame = new Game (Game::FIRST_PERSON_SHOOTER_TYPE);
    myGame->loadMapFile ("myQuakeClone.map");
    myGame->loadCharacterFile ("myQuakeClone.char");
    myGame->loadStoryLine ("myQuakeClone.story");
    myGame->run ();
    }
    ---------------
    Or how is this, a Soldier of Fortune clone written in G

    File: soldierOfFiction.g
    program main (arguments) {

    Game myGame = new Game (Game::FIRST_PERSON_SHOOTER_TYPE);
    myGame->loadMapFile ("mySOFClone.map");
    myGame->loadCharacterFile ("mySOFClone.char");
    myGame->loadStoryLine ("mySOFClone.story");
    myGame->run ();
    }
    ------------------
    Another example of the power of 'G', writing a GrandTourismo clone

    File: grandTourism.g
    program main (arguments) {

    Game myGame = new Game (Game::RACING_SIMULATOR_TYPE);
    myGame->loadMapFile ("Silverstone.map");
    myGame->loadCharacterFile ("DieZweiShumacherTwins.char");
    myGame->loadStoryLine ("formula1_season_2002.story");
    myGame->run ();
    }
    ---------------
    G Allows you to extend games in new and exciting ways, for example
    you can see how well Max Payne compares to Hitman 47 when driving
    hot Honda Civics around the original DukeNukem 3D world ...

    File: wacky_races.g
    program main (arguments) {

    Game myGame = new Game (Game::RACING_SIMULATOR_TYPE || Game::FIRST_PERSON_SHOOTER);
    myGame->loadMapFile ("DukeNukem3D.map");
    myGame->loadCharacterFile ("MaxPayne.char" + "Hitman47.char" + ("FastAndFurious.char" || Game::CAR_FILES));
    myGame->loadStoryLine ("zorak_vs_thundercleese.story");
    myGame->run ();
    }

  117. Re:FIVE OSCARS FOR LOTR by Anonymous Coward · · Score: 0

    They're up to four now...

  118. Re:Whoa whoa! Stop the "portability" train! by Wolfier · · Score: 2

    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.

  119. universal compiling of a program/game by zer0*ryok0 · · Score: 1

    i understand how running the same code on all machines seems nice and all.

    but i have always invisioned a single media
    with a native binary for each system(or systems, OS - in the case of a PC).

    now why not just have the compiler be super smart and knows howto compile for each system that you want it on (since your going to have a JIT for somthing like java anyways)

    and you would program in a generic sound/graphic API that calls the correct libraries for each system.(since thats what a JIT would do anyways)

    it would also deal with each systems hardware
    (lack of/bonus of)

    that way you retain the speed of each system
    and your not programming for set of hardware.

    --zer0

    --
    the only fact is that everything is an opinion
  120. Re:Whoa whoa! Stop the "portability" train! by XBL · · Score: 2

    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.

  121. Think about the upcoming wireless gadgets by Anonymous Coward · · Score: 0

    Everyone is talking about the current desktop/console based game market, but what about all the gadgets formerly known as mobile phones popping up everywhere ? Dont you think mr. average consumer wants to play with his peers during lunch break a nice funny relaxing game ? Here in germany the so called moorhuhn shooter (very simple shooter) almost led to a complete productivity lost in some box offices ... Most of the new mobile phones have at least J2ME built in, the PDAs are already fast enough to run J2SE on (check out www.savaje.com) and there are a huge number of non computer affiliated persons who desperately want to play games although (ever looked at people freaking out on snake on their phone ?!?) I think java makes the ideal candidate as the underlying glue for all the connectivity in the various gadgets we will all use in a few years.

  122. question by Anonymous Coward · · Score: 0

    don't the slashdot janitors get paid now for running this website? i would expect better from even the most amateur of editors.

  123. Java Hardware by nuxx · · Score: 1

    I thought I remembered some Java-specific hardware. Here it is... http://www.inside-java.com/articles/javachips/micr ojava.htm. If we could get one of these in every PC, then would there be any problems with speed? MS seems to hold quite a bit of sway over the hardware mfg's, though. I don't think we'd see this anytime soon...

    -Steve

  124. Amiga promised this last year by Anonymous Coward · · Score: 0

    Seems to me I saw an article at Amiga.com touting the Amiga Development Environment that would offer all of this and more......

    1. Re:Amiga promised this last year by nicomen · · Score: 1

      And it IS available check out http://www.amiga-anywhere.com/ http://amigadev.net/ and the URL I posted earlier with the topic "Been there, Done that, Doing it Anywhere" which shows BIll McEwen taking Flash cards out of one device to another one and running the same game on them. without ANY modifications.

      --
      Nicolas Mendoza
      Prepare for MSIE 7
  125. Now, I can believe that thinking... by Svartalf · · Score: 2

    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
  126. Didn't we see this last week? by Anonymous Coward · · Score: 0

    This is kind of like AmigaAnywhere. The difference is AmigaAnywhere is out now.
    The big difference is you get to program Amiga in C/C++, Java, assembler, Python, etc. With Sun's plans you only get Java. Now Java is fine, but I like some choice.

    Nice try Sun, but this kind of thing is old news.

  127. I just saw this on Sun's site by Anonymous Coward · · Score: 0

    News Alert: Java is Slow.

    for more info:

    http://java.sun.com/JavaIsSlow.jsp

  128. Java Bullshit by k2x · · Score: 1, Troll

    First of all Java is a bullshit language, and yes you could call me a troll. Since it was designed for specific purpose and model, it is difficult trying to force a model onto another paradigm: Games.

    Read what Mr. Sweeney(Unreal.com) has said in past interviews about Java. Java code is just not the type of application you can write games with. I mean, games push billions of bits across your bus and having such a high overhead like java, means you have to settle for games like "Yahoo Pool!". From my experience, using Java for UIs are horrible(u get inconsistent response times from simple things like menus). Now try imagining that for games.

    While I have to agree that Java has some advantages (in my case it eases remote administration of custom developed hardware/software). But please don't advocate Java is the Holy Grail of computing.

    I've seen the same bullshit for C++ on some forums, where ppl just spurt out, "Use C++". I've seen comments where one guy just glanced at the Quake2 source code overnite and complained it lacked any "software engineering" techniques or C++.

    What happened to the days when ppl were more pragmatic?

  129. Re:Whoa whoa! Stop the "portability" train! by bolthole · · Score: 2, Insightful
    It is apparent that the only clear choice for game development is still well-written C. It's fast, clean and, if well-written, far more portable than Java could ever hope to be.

    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.

  130. Amiga by evilpolic282 · · Score: 1

    Isnt Amiga do this ame sort of thing with tPDAs, cell phones, etc.?

    1. Re:Amiga by nicomen · · Score: 1

      And set-top boxes an actually desktop systems too. Take a look at my other posts on this article and you'll find information about it.

      --
      Nicolas Mendoza
      Prepare for MSIE 7
  131. Re:What about Ultra HLE? Interesting implementatio by kubrick · · Score: 2

    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
  132. Q2Java by barryp · · Score: 1

    Yeah, that's my baby: Q2Java - the main thing to note though it that it's just the game logic that's implemented in Java, nothing with the rendering or networking (not to say that that wouldn't be possible given how fast machines are nowdays).

  133. This will never work... by --daz-- · · Score: 1

    Another failed idea by Sun...

    First, it's Java which always has severe performance issues on all platforms but Windows (for some odd reason).

    Second, it's just more of Sun's lowest-common-denominator strategy of do nothing particularly well, but do everything poorly or equally. Don't take advantage of any platform's perks. Just plod along and go with the worst of every platform.

    There is a reason why we have diverse gaming platforms. And it's not simply because no one thought of unifying them.

  134. Re:FIVE OSCARS FOR LOTR by Anonymous Coward · · Score: 0

    ...and the best picture is....

  135. Re:FIVE OSCARS FOR LOTR by Anonymous Coward · · Score: 0

    A RETARDED MIND! Buahahhaha.. lotr suckzerz loose again!! Wait till next year when we got Harry Potter 2! I like Hagrid a lot, do you think he's a bit feminine? Maybe he has male-tits. Just imagine it. I wish I was Harry, cause then I could get that male-tit bear hug, wow! What if it leaked milk?? Oh you havent seen that brad pitt movie? eh?!! Wtf.. anyway i was thinking, wouldnt you like to screw ginny when she turns 13?

  136. I'm sorry but theres no way by HanzoSan · · Score: 1, Troll

    That java will ever be used for games. Its not fast enough. IT never will be fast enough for a game machine.

    Game makers code in Assembly, directly to the hardware to get extra speed, and the rest of their code is in C.

    Tecmo and AM2 both write their games completely in assembly and thats why their games are as good looking as they are and push the hardware like they do.

    Java development? is it a Joke? Only lazy American PC developers would use Java.

    --
    If you use Linux, please help development of Autopac
    1. Re:I'm sorry but theres no way by vortexau · · Score: 1

      That's already being implimented......

      Amiga Anywhere-

      (Hardly a 'DEAD' topic :).... )

      .

      --
      (David Bowman, EVA near HUGE Monolithic Win-PC in orbit around Jupiter) "My God - its full of Malware!"
  137. Re:FIVE OSCARS FOR LOTR by Anonymous Coward · · Score: 0

    I'm sorry, but there was a mistake, we um, eh made a boobie, sorry. Anyway, "A Beautiful Mind", still gets to keep the shiny naked golden male with a sword very close to his penis, and we'd give a new one to "The Lord of the Rings". Also, any idea where Tolkein went off to? Last I saw, he was staring down Drew Berrymore's ....

  138. Game Developers use assembly by HanzoSan · · Score: 2

    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
  139. Console games? by HanzoSan · · Score: 2

    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
    1. Re:Console games? by horse · · Score: 1

      I admit to not caring about console games (I don't like the interface), but I doubt seriously that they don't use libraries. Even old DOS games used libraries for some things.

      It used to be that most PC applications were written in assembly (circa, say, 1984-1985). Things change. I would guess that they will change for consoles as well, and for the same reasons.

    2. Re:Console games? by Anonymous Coward · · Score: 0

      "Face it, Console developers write their own libraries, they have their own tools, and they write alot of the game in assembly."

      Which is exactly why they would gain so much if they used Java where they wouldn't have to re-write so much low-level stuff...

      Face it: QUAKE 3 - THE GAME is written in an interpretted C-like script - much slower than Java. It is built on the fast game engine that deals with the 3D stuff - a lot of which is handle mainly by the hardware and openGL/DirectX - EXACTLY the same as it would be for Java.

      The Java 3D provides a decent scene-graphed based 3D library that has been used succesfully for realtime first person shooters (JAMID) and an F1 racing simlator - theses were shown at GDC - that's proof enough that it can be done.

  140. AI ? by HanzoSan · · Score: 2

    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
    1. Re:AI ? by Com2Kid · · Score: 1

      I know that Java is ass end slow for games, but above posters DO have a point, as CPUs get faster odds are developers will get laaazzier and laaazzier and be willing to waste large amounts of CPU cycles for that one time reduction in time taken to program the game. Bleh.

      The more advanced AI algoriths _DO_ rely upon hardware optimizations though, not to mention cache size (heh). And RAM size, if you cannot load the pathing files for the AI into RAM for a level. . . . well now that just plain ol' sucks! Thus a programmer might have to resort to using a less efficent but smaller pathing data format so as to get it all into the RAM on console X but on console Y be able to use the full blown deal.

  141. it defeats the purpose by SouperDouper · · Score: 2, Insightful

    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.

  142. Gamecube can do things PS2 and Xbox can't, vice-v by dolphin558 · · Score: 1, Informative

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

  143. virtually impossible by Anonymous Coward · · Score: 0

    a) Nintendo, Sony, and Microsoft collect money on each disc for their system. So you get to pay each company $5-10 per title now? That'll go over well with publishers..

    b) The GameCube uses DVDs that are physically smaller than normal DVDs, so that'll dictate the medium used for storage at best, at worst require a seperate medium for each platform, leaving us where we were in the first place..

    c) Is it even possible to to create a disc that will boot on multiple platforms or do you get a GameCube, PS2, Xbox, Windows, Mac, and GNU/Linux boot disc in each case, plus the actual game disc? :)

    d) The PS2 has horrible regular integer performance compared to the GameCube and Xbox. Actually the PS2 performs aweful in general. Unless you're willing to invest a few man-years rewritting your portable code into carefully optimized asm for the vector units.

    e) What kind of games can we reasonably expect? There is a huge performance difference between the GameCube, the PS2, and a typical consumer PC.

    f) We can't even get games to work properly on Windows after 8+ years, how could things possibly on more platforms in less time?

  144. Amusing coincidence by Trepidity · · Score: 5, Funny

    Two consecutive Slashdot stories:

    -- Platform Independent Gaming?

    -- Ask Slashdot: Most Outrageous Vendor Lie Ever Told?

  145. Re:ugh, yes, it will never play the newest games.. by Graspee_Leemoor · · Score: 2

    "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

  146. Not console developers by HanzoSan · · Score: 2

    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
    1. Re:Not console developers by Com2Kid · · Score: 1

      The Japanese had this awful habit of using the same tired old PC systems for ages. . . . . I mean OOLD. They had a standard setup for PCs, basicaly windows3.1 machines, heh. Sucked.

      Annyways. A TON of interactive storybook style adventures, nice Genre, but hardly hardware limited. :) Took'em forever to get off of 8bit color. :(

      PC games and console games leap frog each other, and in fact it is one that encourages the continual development of the other.

      Oh and if some asshole in finances says that a company is going to use Java to program their next 'big hit' in then guess what;

      the company will end up (trying to) programing it in java.

  147. Not that simple by hyrdra · · Score: 2

    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
  148. Java Performance by Anonymous Coward · · Score: 0

    Obviously Java, C, etc can not match a good programmer's asm, but people should quit assuming Java is slow.

    Check out Transmeta's code morphing; they thought it was faster to emulate than actually execute the code.

    Check out HP's Dynamo project; they were actually able to emulate a faster chip than was actually running. Yes, a 400Mhz chip was performing like a 500Mhz chip. "Emulation" was speeding things up to faster than the chip could excute the code natively!
    http://www.hpl.hp.com/cambridge/project s/Dynamo/

    Arstechnica has a great little write up about it:
    http://www.arstechnica.com/reviews/1q00/dynam o/dyn amo-1.html

    Java simply hasn't had time to mature, any day (or year ;)) we can expect some awesome speed gains from Java runtimes. Check out IBM's benchmarks of their latest Java runtime:
    http://www-106.ibm.com/developerworks/ja va/library /j-native.html?loc=j

    Sun's JDK took 67 seconds for executing a prime benchmark while the GNU Compiler Collection produced native program executed in only 40 seconds.

    However IBM's JRE beat both by taking only 18 seconds!! In SciMark both Sun and IBM beat the native executable.

    Java is not too slow as an alternative to any HLL.

  149. cutting edge graphics are impossible by Anonymous Coward · · Score: 0

    As a professional developer who is currently porting a C++ game from the GameCube to the Xbox I'd like to point out how difficult it is to get maximum performance between multiple platforms.

    It would be impossible for us (or anybody!) to write our own API, Java or not, that works on just the GameCube and Xbox (forget about the PS2 for a minute because its a given that you'll have to do significant work to get peak performance out of that damn machine) without sacraficing performance. ALWAYS somebody would be able to come in and write a a native which beats one graphically that doesn't contain any platform specific code. ALWAYS.

    A publisher will always put up funding for a couple man years (1-4 people*$50k/year) of labour to rewrite a game so that it has competive graphics with the native games. The savings in programmer cost certainly don't justify the lost sales.

    Also now each platform really favours enhanced "ports". If you release an old game, but make stupid little changes to the story that gamers generally complain about the publisher and console maker will be much happier.

    However if you're working on a puzzle game or something this may mean you can hire 1 programmer and have a product that can quickly be recompiled and shipped for each platform you want to support. Of course the gama, etc will be different for each platform, but nobody will care unless it looks horrible on one.

  150. An Easier Way to Make Games Cross-Platform by MadFarmAnimalz · · Score: 2

    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.
  151. Wrong idea. needs to go this way. by LohRhyda · · Score: 1

    Now a game that controls itself as like a operating system is what is really needed. you dont have to worry about your o/s sucking resources to play your high end game.
    Instead what i would see is the game as the enviroment. Now yes this would stop you from being able to do anything else at the same time.
    But in reality Who the hell plays games the same time they are reading the paper online?

    --
    EOU
  152. Come on Java is no more interp. : heard JIT ? by Anonymous Coward · · Score: 0

    Sad that you still use the interpreted word :(

    Heard about JIT compilers ? All the Java VM's got it nowadays ?

    Second thing, you said it's slow but slow regards what ? good C programer ? hardcore x86 ASM coder ?

    Byt using embed pooling techniques for instance the famous Swing intern standard facility the VM is far much faster than common C/C++ libraries on most needed fonctionality (thanks to the immutability of String that enable damned fast sort/equals/compare ...)

    Anyway on some opration, btw brute force operations like matrix cross on ordinals for instance then C/C++ hit the road !

    On my 4 years Java and 6 years C/C++/ASM experience....

    Java performance nowadays is in a -15% +15% range. ie, sometime you get 15% slower that a C software some other you get 15% faster !
    Just because the JIT stuff is going smarter and smarter in optimization stuffs inlining and optimisation of algorithms are quite impressive and event if this is not real machine code :who cares as long as it is fast to fit my needs ?

    NB: what is exactly native machine code btw ? Is x86 instruction set still the "native" PIII or P4 instructions ? looking at the core translating techniques you may doubt it is ;-)

    Any ways, MAJC is nice but i also like the Jazelle stuff from ARM which is now default embed in their new processors :o)

    As a conclusion : If you are a core ASM gamer and know perfectly the linux internals then go to help the blackdown.org http://www.blackdown.org/
    project they need your help to work on the VM optimization on linux to kiick the Win32 supremacy out of Java !

    I also encourage you to go and download the Java2 Source code and have a look at it : yes it is free and available for anybody that cares for sun's site http://developer.java.sun.com/developer/products/j ava2cs/ for a download :o)

    4R34'.

  153. think about it by carpe_noctem · · Score: 1

    If they get full support for it I can finally get rid of that windows gaming partition!


    Well, perhaps there's an argument for why platform-independent gaming is rather unlikely to occur, given that windows and xbox together represent the largest gaming platforms in the world. Hopefully, this won't be like Java (as in a platform independent idea supported by everyone but microsoft)

    --
    "Quoting famous computer scientists out of context is the root of all evil (or at least most of it) in programming." - K
  154. Try NASCAR Racing 2002 Season. by Blaede · · Score: 1

    There is not a consumer system (even dual CPU) that is able to play this game with every option on at 1600x1200x32 (with uncompressed car textures, all 43 of them at once) and be able to give you at least 30fps. This is one game that truly punishes computers.

    1. Re:Try NASCAR Racing 2002 Season. by Anonymous Coward · · Score: 0

      Crappy code; place your bets.

  155. games in java already here by Anonymous Coward · · Score: 0

    check this please http://www.radicalplay.com

  156. Re:DVD, DVD, and DVD - ish, anyway. by iainl · · Score: 1

    Unfortunately, the actual answer is basically DVD, Sort of DVD and Even Less Like DVD.

    PS2 is DVD with a couple of intentionally mangled sectors for copy protection reasons, just like the PSOne uses a mangled CD for its data.

    X-Box is DVD with the boot sector at the start of the second layer, so its on the outside and early data will be faster. Also, current home DVD writers only do single layer discs, so copy protection is added as well.

    Gamecube is a DVD-Mini (8cm DVD) with the boot data in the second layer again, but for added fun the layers are upside down (second layer is now the first layer and vice versa). This way a normal DVD drive can't even focus on the data as the spiral for the layer its looking at goes in the opposite direction to what its expecting.

    So you really can't have a data disc read by all three at all.

    --
    "I Know You Are But What Am I?"
  157. How about some research before writing? by catseye_95051 · · Score: 2

    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

  158. This was just discussed... by crisco · · Score: 2
    This was just discussed in /.'s developers section.

    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!

  159. And the first Java Gaming Profile title is... by Anonymous Coward · · Score: 0

    text mode pong!!!
    http://www.karber.net/textbased/pong/

  160. Java speed Amiga2000: Dungeon Master Java by alapalaya · · Score: 1

    I guess it is possible to have good games written in java. A good example is Dungeon Master Clone which is a very good clone of the original Amiga game (loved it!).
    So actually on a moderate hardware your Java environment is little faster than an Amiga 2000.
    In a future it could easily become better... even if actually 80% of games (90% of console games) use almost all system resources, but, beware: it is always possible to code in a Java environment and use common APIs which are implemented as native system calls (by the JVM) for high performance tasks as 3D.
    If such JVMs are designed on top on exsiting, or future, consolle, you could have a Java environment 80% as fast as native C environment. It could work.... maybe!

    --
    667 The Neighbour of the Beast
  161. Uh yeh. by Anonymous Coward · · Score: 0

    Unforunetly, manualy filtering out all those 'shemale' sites takes its toll on your mind. don't ever run a porn site.

  162. Have you ever tried? by autopr0n · · Score: 2

    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.
  163. no. by autopr0n · · Score: 3, Insightful

    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.
    1. Re:No. by cies · · Score: 1

      But then it wouldn't be platform independent, right?

    2. Re:No. by acidblood · · Score: 2

      Wrong. Java is compiled to an intermediate representation (bytecode), and later translated to the machine's native instructions by means of the JVM. Reverse engineering the bytecode is every bit as hard as reverse engineering ordinary assembly code for any processor.

      --

      Join the NFSNET. Our prime goal is making little numbers out of big ones. http://www.nfsnet.org/

  164. What about modern assemblers? by Anonymous Coward · · Score: 0

    Which do things like convert one instruction "li" into a pc-relative load and then stick the constant in some random place.

  165. I don't know about him by Anonymous Coward · · Score: 0

    but I wrote largish programs as DATA statements, i.e. in machine code. I guess you were one of the rich kids who could afford an assembler. You probably had a disk drive too, instead of using tape...

  166. Hypocrite!!! by autopr0n · · Score: 2

    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.
    1. Re:Hypocrite!!! by thomas.galvin · · Score: 1

      No no no, I don't use it....I've just opened up the code to the public. :)

  167. Its 2002 and ARM rules by Anonymous Coward · · Score: 0

    If you want decent performance out of a GBA, you use ARM for certain routines. True, we don't write the whole front end in asm like we used to on GBC, but any game trying to look pretty will have a bit of asm in it.

  168. That's not machine code. by autopr0n · · Score: 2

    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.
    1. Re:That's not machine code. by AndrewHowe · · Score: 2

      Only in a use16 code segment ;-)

  169. I could plug "Eggo mania" here by Anonymous Coward · · Score: 0

    which is coming out soon from Kemco (multi-platform), has great gameplay, but its simple graphics could have been done in Java. But it did take several weeks of development to port it from one platform to another - of course most of that was graphical enhancements and gameplay tweaks rather than porting.

  170. When I last looked at java by Anonymous Coward · · Score: 0

    someone had got it to read in a 1k text file and write it out. This took 30 seconds. Thanks, i'll stick to commodore 64 basic thank you.

  171. Sun wanted to kill Java by Anonymous Coward · · Score: 0

    that's why they sued Microsoft to get them to remove java support from windows.

  172. 32768 colours! by Anonymous Coward · · Score: 0

    or is there some special bitmap mode I haven't found mentioned in Nintedo's docs?

  173. There are 5 platforms by Anonymous Coward · · Score: 0

    PS2, Xbox, GameCube, GBA and PC. Probably in that order. And some legacy stuff for PS1 and possibly GBC.

  174. You may want Karma to be native also by Anonymous Coward · · Score: 0

    since it is becoming quite popular and will chew up a few cycles.

  175. Sega by autopr0n · · Score: 2

    Sega made the dreamcast.

    --
    autopr0n is like, down and stuff.
  176. No. by autopr0n · · Score: 2

    Just like how you can't see the sourcecode to any compiled java program, moron.

    --
    autopr0n is like, down and stuff.
  177. java development cycle by Anonymous Coward · · Score: 0

    one problem I see with java gaming is the update cycle of gaming hardware (e.g. latest graphic cards): sun releases a new java version every 18-24 months, and that's not enough for high-end games.

  178. But does it run on any games machines? by Anonymous Coward · · Score: 0

    or just those office boxes you mentioned.

  179. Firms won't go for it.. by hyphz · · Score: 1

    PC firms won't go for it because they already try and write games to run on all PCs.

    Console firms won't go for it because it's to their advantage to make games platform dependant.

    Games developers won't go for it because console firms won't go for it.

    Sorry.

  180. Copy-protection anyone? by cefek · · Score: 1

    There's going to be one big problem, regarding copy-protection shemes. As we all know, Safedisc is for PC only, PS2 uses their own DVD copy protection (and their own bootloaders, which must be present on DVD), Xbox probably uses something different.

    If there was no copy protection, there'd be no games for sale.

    --
    Plain old sigh.
  181. It will NEVER WORK!!! by greggman · · Score: 1

    For the simple reason the platforms are TOO DIFFERENT.

    Most games are already portable in the sense that the high level code, the game, will compile across platforms. Every company already has I/O APIs, Video APIs, Sound APIs and maybe even cross platform graphics APIs but those are less likely.

    The problem is not the language, the problem is the difference in Machines.

    A Gamecube has 24 megs all of which is accessable for textures. A PS2 has 32 meg plus 4 meg texture space. An X-Box has 64 meg multi-purpose memory. That means, in order to make a portable game regardless of the language you'd have to make it fit in 24 meg AND never use more than about 3 meg of textures unless you want a sucky framerate on one of the platforms.

    This will effectively make most products not competitive on certain platforms.

    Oh yea, and Gamecube has 1/3 the disc space AND only X-Box has an HD. There went several more portability issues.

    There's also the graphics engine issue. Lots of people are pointing out you could make Quake in Java. So What!!!! We don't want Quake, we want Dead or Alive 3. We want engines like Jax and Daxter that are pushing 250k+ polys per frame at 60hz. Those kind of things require custom code on each platform, not write once code that works on generic lowest common denominator 3D engine.

    This Java system is going to give you N64 quality games on your XBox. When XBox 2 comes or our PS3 you'll get last generation's games using such a generic system. Sure, we'd all like to believe that all that matters is that the game is fun but check the market stats and you'll see, flashy graphics sell and flashy graphics require platform dependent coding at which point Java saving you exactly zero.

    To some up.

    1) It's the data, not the code that's more important for portability. Java works great on the net with generic interface widgets. It's portability goes out the window though as soon as ever gadget needs different data.

    2) 3D Engines matter. Java won't make your high level code any more portable than it already is and it will not help make your 3D Engine portable since that engine must be platform specific to be competitive.

  182. Yes...Java CAN do it! by Anonymous Coward · · Score: 2, Informative

    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.

  183. Or just use PyGame by acb · · Score: 2

    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.

    1. Re:Or just use PyGame by Peter+Harris · · Score: 2

      Yes, indeed. I am playing with OpenGL in pygame at the moment, and really, it's fast enough for a decent 3D game.

      The graphics card is doing all the real work, and the OpenGL library is written in C, so that's as fast as it can get no matter what language is driving it.

      All the Python bit is doing is deciding where the polygons go and what pretty textures to put on them. You don't need raw horsepower for that.

      So, all the "but Java is too slow" posts are just spouting or trolling. If Python is fast enough, so is Java.

      --

      -- What do you need?
      -- Gnus. Lots of Gnus.
  184. My Plaything... by rirugrat · · Score: 1
    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.

    I want a disk that I can pop into my Sega Dreamcast, my DVD player or my Linux/Windoze PCs so that I can "enjoy" Tera Patrick and Jenna Jameson no matter where I am! :)

    Chris

  185. And I suppose it will be named... by mikeee · · Score: 3, Funny

    IndirectX?

  186. Java fast, gc slooooow by spells · · Score: 1

    Java may appear fast enough while running the most demanding games for a short time, but garbage collection is slow. Imagine your favorite game stuttering for 5 seconds while memory is freed. Although managed memory is the best java feature when performance isn't critical, it sucks on long running, performance intensive apps.

  187. This is supposed to be a good thing for consoles? by Guppy06 · · Score: 2

    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.

  188. Sure, there is a way... by joto · · Score: 2
    Writing systems software in a high-level language? High-level languages will never be used for writing systems software. It is not fast enough. It will never be fast enough for systems software. OS developers, library writers, etc.. code in hex, directly to the hardware to get extra speed, and the rest of their code is in assembler.

    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:

    1. Time to market
    2. That it actually works
    3. That it is has interesting gameplay, and not just impressive graphics

    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.

  189. Yep, but not on a Mac....... by shpoffo · · Score: 1

    because we all know that Java hasn't been implemented for Mac OS - so there's no way you could play java games on a Mac....

    -shpoffo

  190. Sun's Gaming Pipe Dreams by webzombie · · Score: 1

    Come on. Someone need to trip on over to Scott's office and give him a good slap up side the head.

    Java on the XBox. Please!!!

    I remember when Sun was quick to jump all over MS or anybody else for that matter whenever they would release "white" trash like this.

    On what planet does Sun think Sony, Microsoft, Nintendo, whoever are going to buy into one disk many machines.

    Not in our live times I bet.

    Java on the XBox... that's also too stupid for comment. Java on the XBox... geezz...

  191. Heh by mlylecarlin · · Score: 1

    Yeah... just like java was going to revolutionize the web, making operating system totally irrelevant. I see more Flash than Java, and it plays better too.

    mlylecarlin

  192. Games drive the industry by Ridgelift · · Score: 1

    IMHO, games drive the computer industry. If a common code could run on all platforms, it would do more to break Microsoft's stranglehold on the desktop than anything.

    Time and time again, I see people spend money they don't have to buy a new computer so they can play the latest game. Hardware vendors provide the top game producers early access to their newest hardware so that tomorrow's hottest games will run oh-so-much-better with a new video card, new processor and more RAM. People justify their spending by saying they need the speed to be more productive.

    I hope the trend to "pay once, play anywhere" becomes a reality. Then my neighbour won't be so reluctant to spin up Mandrake, since he will be able to play Quake IV without paying his tithe to Redmond.

  193. How about OpenML by Anonymous Coward · · Score: 0

    Heres native way to do games and more
    http://www.sgi.com/newsroom/3rd_party/042401 _khron os.html

  194. Platform Independent Gaming by BarefootClown · · Score: 2

    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

  195. Re:Whoa whoa! Stop the "portability" train! by wurp · · Score: 2

    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.

  196. A non-technical reason for this JGP not to be used by TruthSeeker · · Score: 1

    I believe that this software will never be used by game companies ; sure, it would be fine for it would shorten the porting effort. The problem i'm thinking about is related to Java code being easy to reverse engineer.

    I do not believe there is an easy way - except downloading a private decryption key from a server each time the game is started - and even this would not be 100% sure (because you may sniff the key or whatever)

    So do you really think game companies would ever release a product that would be so easy to reverse engineer ? No, I'm sure they wouldn't - it'd be "dangerous" for their precious revenue streams.

    I'm sorry to see that once again the money which should lead the evolution of the industry ahead will block and stop that evolution.

    --
    I sense much beer in you. Beer leads to intoxication, intoxication leads to hangover. Hangover leads to sobering.
  197. Re:Whoa whoa! Stop the "portability" train! by Wolfier · · Score: 2

    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 :)

  198. As if Java isn't slow enough by timecop · · Score: 0, Insightful

    Now we have this?
    Cmon, let's beat it already. Java is dead. Deader than BSD. C# is the future, and (unlike some mexicans will have you believing) only on Microsoft platform.

  199. Re:Gamecube can do things PS2 and Xbox can't, vice by Ziviyr · · Score: 1

    I'm not sure I would want to purchase these games because they couldn't utilize the advantages of each console. What if I like Gamecube because of the way it uses anti-aliasing? Well, the AA capabilities of the PS2 pale in comparison and a universal game would have to accomodate the PS2's weakness.

    Umm, actually the PS2 interpreter can just ignore the fancy texel filter flag and look ugly with no impact on the GC version. Not that I'd know what GC would do with all those R and L button definitions or what PS2 would do when asked to store 40 megs of data in RAM, and they'd both suffer when something decided to cache something to harddisk. :-)

    --

    Someone set us up the bomb, so shine we are!
  200. Re:What about Ultra HLE? Interesting implementatio by Anonymous Coward · · Score: 0

    ...Project 64...

  201. Games Industry realities. by james(honest) · · Score: 1

    Mass market games are about money. They cost money to develop, to advertise and to distribute. Certainly there are many great community, grass-roots, hobby games out there and java may be ideal for those, but this story was about the xbox, ps2, gamecube etc.

    First, Sony, Nintendo and Microsoft will always attempt to strong-arm developers into producing single-console titles. "Only for XBOX" boasts one-time-Mac-developer Bungie about Halo. So who Sun think they are fooling is anyone's idea. In fact, one can find a way that Sun has competed directly or indirectly with all the major players. Sony and Nintendo use MIPS processors, and the N64 used SGI technology. The Xbox, and, for most people, the PC, is owned by Microsoft. Nuff said.

    I dont see what Java can do for games that flash, virtools, renderware cant do. Class "A" titles are frankly more concerned by how long it takes to load a level, than by easy of portability. Halo and Jak&Daxter are both touting their "instant-loading" abilities. Imagine if the JITC had to compile the level before loading! I did find it terribly amusing that the clever fellow who pointed out how JITCs can compile for all sorts of different processors ever so well and how I, the developer, can instruct the JITC to compile the code just once, unfortunately forgot, or was blinded by his own brilliance, that neither the ps2, nor gamecube, have a harddrive.

    So, if we limit our discussion to the PC, why dont I just use C#? The developement environment is infinitely better than anything for less than $5000 and its guaranteed to run on 99% of all game-playing PCs.

    Sorry, Sun, you had your chance at making Java a generic gaming scripting engine, but that was years ago when you were still a bunch of arrogant fuck-heads who thought Java was amazing and we could all bloody well pay $100,000's for it. Now that C# arrives, you're so keen to push Java for games. Hmmm. See ya!

    1. Re:Games Industry realities. by james(honest) · · Score: 1

      And I should just say that I called it a generic gaming scripting engine because it is. We've been using VMs in games for decades, we just didnt call them that. So, Java is like "so what?" for most of us.