Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Java Programming

Evaluating Java for Game Development 76

Posted by michael from the gotta-be-useful-for-something dept.
Jacob Marner writes: "A large independent university report has just been published that examines whether Java is useful for professional game development."
This discussion has been archived. No new comments can be posted.

Evaluating Java for Game Development More

Evaluating Java for Game Development

Comments Filter:

  • Conclusions... (Score:2, Insightful)

    by Unruly ( 249984 )
    In contrary to popular belief, Java applications are in fact not much slower than C++ applications when they have been tuned for performance. A rough estimate based on the various benchmarks would say that tweaked Java code is a little slower than C++; typically 20-50% on the average, but this is hard to tell for certain because of the large variations in the speed seen in the benchmarks....

    20-50% is "not much slower" ??

    Say I had two programs, one done in all C++ and one done in all Java

    Now, if these numbers are right, then the C++ program is up to TWICE as fast as the Java one... I think I know which one I'll be using.

    • Re:Conclusions... (Score:3, Insightful)

      by Zach Garner ( 74342 )
      > Say I had two programs...

      But you don't! Instead, you either have a Java one or a C++ one. You don't get to chose. It's the people developing the games that make the choice.

      Two more conclusions from the article:
      1. The slowdown is less [than 20%] in 3D applications.
      2. There is a 65% increase in productivity.

      In addition, this paper makes a note that Java is useful for games that are not tied to performance and for low profile games.

      For these games, the decrease in speed is not important, but the amount of money spent on the project is.

      We've long since passed the point where programmer time is cheaper than hardware time.
      • 1. The slowdown is less [than 20%] in 3D applications.

        Java3D is written in C/C++. Thus the Java program feeds the C/C++ layer with the necessary data and control, which in turn feeds the graphics processor, which does the work. The additional time is needed to transform Java Objects out of the VM into C Objects and back.

        Is this bad? I don't think so. What I don't like is that Java is marketed as plattform independent, which it is not, large parts are implemented as native code. Java is easy to use on the 4 supported main platforms (Solaris, Windows, Linux, Mac OS X), otherwise one has to hope that a porting effort is underway (like in case of FreeBSD).

        2. There is a 65% increase in productivity.

        Most good Java programs I have seen yet are integrated development environments. It is really amazing how many IDEs are written in Java. Some of them being very good ones.

        Add to this the large, standardized libraries, and the dumbed down syntax in many areas, compared to C++. While I judge 65% a bit high, development with Java sure is quite comfortable.

        • Java3D is actually based on OpenGL. Yes, that means that there is C code running at a low level (i.e., the OpenGL implementation provided by each graphics card provider), but that is no different that *any* language other than C that uses the OpenGL standard, including C++.

          I agree that Java may have missed the mark, as far as performance-intensive applications like games are concerned, but given that people are seriously interested in Python-based game development (as evidenced by pygame, PyOpenGL, etc.), I think it's hardly reasonable to attack it on the basis of performance.

          Personally, I'd rather hear the opinion of someone who had actually worked on commercial-scale gaming projects. For those of you who have actually worked in the field, what features were present (or missing) from your choice of implementation languages and platforms that would have improved your productivity, or the quality or performance of the finished game?

          • Re:Conclusions... (Score:3, Interesting)

            by mvw ( 2916 )
            Java3D is actually based on OpenGL.

            No, for Windows you can either choose a version using Direct X or one using OpenGL for rendering.

            Yes, that means that there is C code running at a low level (i.e., the OpenGL implementation provided by each graphics card provider), but that is no different that *any* language other than C that uses the OpenGL standard, including C++.

            My complaint is that there is no Java3D version that is portable and free at the same time. But that is my general problem with Sun's Java licensing.

            I agree that Java may have missed the mark, as far as performance-intensive applications like games are concerned, but given that people are seriously interested in Python-based game development (as evidenced by pygame, PyOpenGL, etc.), I think it's hardly reasonable to attack it on the basis of performance.

            The present Java games are not bad. But they are the same league, like games written in Flash are. Hard to imagine a Java title would show up in the games top 10, and this mainly due to the fact, that most top titles try to really use the hardware at its limits, thus performance is an issue.

            Personally, I'd rather hear the opinion of someone who had actually worked on commercial- scale gaming projects.

            Java gaming [javagaming.org] is a good resource. Several of my colleagues are former game professionals. They watch the Java game development community with great interest. As far as I can tell, their opinion on Java for gaming seems to range from promising to not suitable (at least not for Quake III like games, where state of the art 3d engines are needed that squeeze out every cycle).

            The crucial question for them is if you can make money with such a title, which seems to be not easy in the games industry. Perhaps it will be in the mobile phone market?

            • "Hard to imagine a Java title would show up in the games top 10, and this mainly due to the fact, that most top titles try to really use the hardware at its limits, thus performance is an issue."

              Weird - I thought that "The Sims" were constantly in the Top Ten.
            • >> The present Java games are not bad. But they are the same league, like games written in Flash are. Hard to imagine a Java title would show up in the games top 10, and this mainly due to the fact, that most top titles try to really use the hardware at its limits, thus performance is an issue.

              Examples of game made in Java that has been on the top ten: * Who wants to be a millionare * Vampire - The masquerade * IL-2 Sturmovik

              The last two had very good performance. Note that none of this was made in "pure" Java but in a mix, as suggested in the report.

              Jacob Marner

      • the report indicated that static compiler have to pay price! and thats not good for anyone to shipp huge sun's .DLL with a tiny .exe one...! wondering how hotspot can just spot the core codes when Quake like giant games are wirtten in java!! small games are ok! but its not that easy to catch up the speed of C/C++ without paying a terrible price!! npguy ysgnet.com

      • But you don't! Instead, you either have a Java one or a C++ one. You don't get to chose. It's the people developing the games that make the choice.

        I do get to choose. I simply to not buy/use the slow programs and find faster alternatives.

        2. There is a 65% increase in productivity.

        All my code base and all the libraries I use and are accusomed to are C++ libraries. If I have to learn to use a new library and throw away my existing C++ code base almost entirely, how does that improve my productivity by 65% ?

        For these games, the decrease in speed is not important, but the amount of money spent on the project is.

        So, the conclusion is basically that Java is ok for small applications, wether games or otherwise, but for anything larger in scale the language/environment of choice should still be something else (C++ for instance).

    • As time goes on, performance will become a more difficult thing to predict, I think. As AI takes more and more cycles, efficient coding structures for handling complex data will make more and more difference.

      I don't write better code in Java than I do in C++ - but perhaps others do.

      .

    • Re:Conclusions... (Score:1, Informative)

      by Anonymous Coward
      >> Now, if these numbers are right, then the C++ program is up to TWICE as fast as the Java one... I

      No this is not right. Page 33 says:

      >> That Java is a factor of x slower that C++, means that Java uses x times more time
      than C++ to perform the same computation.

      So a slowdown of 50% means that is is 1.5 times slower.

      Jacob Marner

    • Re:Conclusions... (Score:1, Funny)

      by Anonymous Coward
      Sure, why don't you go to assembler and get even more speed up.
    • Say I had two programs, one done in all C++ and one done in all Java Now, if these numbers are right, then the C++ program is up to TWICE as fast as the Java one... I think I know which one I'll be using.
      As it reads on the website:

      Important: As stated on page 33 of the report; when the report uses the phrase X is 30% slower than Y, then this means that X uses 30% more time than Y to perform the same computation. This is the same as saying that X is 1.3 times slower than Y. So if X is 50% slower than Y, this does not mean X is half the speed of Y.

      This means that a Java version would take 1.2 to 1.5 times as much time as a C++ one, NOT 2 times as much.

  • No question, really. But not soon. (Score:3, Informative)

    by Snowfox ( 34467 ) <snowfox@@@snowfox...net> on Friday March 08, 2002 @10:53PM (#3133909) Homepage
    I make games for Midway Games [midwaygames.com]. Here's my perspective as a console developer...

    In my mind, there's really no question about whether Java itself is useful, or whether it could clean up the development process. It is, and it could. I don't doubt that in the near future, we'll see a game system for which most games are written in Java.

    The current limitations are these...

    First, using a language like Java, despite all that you hear and believe, demands additional processor time and additional space. Only one or two current game systems are up to the task at present. You won't see a change until all current-production systems are up to the task, because virtually every game development house is leaving the option of a universal port open, if they're not already targeting all three major systems. Nobody likes closing their options.

    Second, because game systems have typically been very restrictive in terms of RAM size and CPU power, most game developers are accustomed to working at a very low level. They're used to cycle-tuning. They want complete control over the system. Getting most to even consider C++, let alone something as far removed as Java, is an uphill battle. There's a lot of cultural baggage ("this is the way we've always done things") to shed, as well as a lot of relearning to be done. Eventually, it will probably be imperative that Java or some universal event-driven scripting toolkit is adopted. But for as long as possible, the majority of the individual established game developers - the ones who are usually in charge of complete production teams - will avoid making any fundamental changes to their tools.

    Next - we work with the tools we're given. Not a one of Microsoft, Sony nor Nintendo have been pushing Java. Accordingly - most of us haven't even evaluated the possibility. The concept is far enough removed that we still joke about whether being a Java programmer is an oxymoron.

    Lastly - who wants to be first? Somebody's going to have to take the plunge. Until someone who's - due to personal preference or financial incentive - just gonzo java-crazy jumps in and makes a well-performing Java-based hit, where's the guarantee that going Java is even safe? It's good in theory... but so was WinCE-based Saturn development, and you saw how many hits came from that approach. (Hint: They all have WinCE startup screens, so you'd know if you ever even saw one.)

    • ps - for Midway, you have to click here [midway.com] instead. No idea what the hell's going on with www.midwaygames.com dns resolution. It used to work.
    • There was an article about someone wanting to write a multiplayer game engine in C# not long ago. I posted something very similar [slashdot.org] then. I have yet to talk to anyone who has actually made games professionally and has seriously considered using Java. But a lot of people, many of whom are experienced programmers outside the gaming industry, who haven't seem to think it's a good idea, it comes up all the time.

      Skimming the paper in question, the author even says that Java development is not recommended for consoles, and in fact using it is not even possible in most cases. Furthermore, he wisely realizes that it may never be possible for the X-box. His final conclusion is that because of the lack of console availability and due to performance considerations, Java is only feasible for low profile games or high profile but low performance games, and of course only for PC-only games.

      As you say, somebody would have to take the plunge first. But I can't imagine who it would be. The problem is it's going to be very hard to convince an experienced developer like you or me to try it for a long time to come, and inexperienced developers have a big enough learning curve to get over without also trying to blaze a trail in a new language.

      Unlike you, I do doubt that we'll a system that uses Java as it's primary environment any time soon. It won't happen on the current generation of consoles, and I highly doubt it will happen on the next. Beyond that, it no longer fits my definition of the near future. It's too many product cycles down the road to make any reasonable predictions about what people will be using. I do think we'll probably see Java being supported in the next generation (PS3, GameHypercube, Y-box, whatever), but not widely used.
      • > I have yet to talk to anyone who has actually made games professionally and has seriously considered using Java.

        nGame. Not consoles (or PCs), but they do use a Java based system.

        http://www.ngame.com/corporate/technology.html
        http://industry.java.sun.com/javanews/stories/stor y2/0,1072,37890,00.html
        http://www.wirelessgaming review.com/articles/ngame 072701.php
    • I thought the WinCE stuff didn't come into play until the Dreamcast. And, much to my biased chagrin, there were a few WinCE titles, most notably the Sega Smash Pack series. Part of the Saturn's downfall was that it was too difficult to program with it's various chipsets and such.
  • I wrote a fairly simple game with Java recently. It was my first full-blown java application, so take my perspective as you see fit. This was also a few months ago, and I've lost interest in the project...

    Executions speed wasn't an issue. But the tradeoffs java makes in order to be multi-platform were. Although the java API seems to allow tracking the mouse, with win2k (using Sun's JRE), I couldn't track the mouse while the button was being depressed. I got the mousedown and mouse up events, but I couldn't tell what happened to the mouse inbetween.

    Another issue was that images would sometimes be loaded across the network in the middle of a screen redraw, causing unacceptable slowdowns, and the entire screen would be redrawn, rather than just the invalidated rectangle.

    As I said, I gave up on the project before trying too hard to work around those issues. As I'm currently knee-deep in the Windows GDI API, the Java standard classes look better and better each day.

    --lb
    • oh, one more benefit of java - since each class is compiled into it's own .class file, it's potentially easier to upgrade a few classes. With C, you'd need to relink, or create a new .so, or deal with dll hell.

      • oh, one more benefit of java - since each class is compiled into it's own .class file, it's potentially easier to upgrade a few classes. With C, you'd need to relink, or create a new .so, or deal with dll hell.

        That's not really an issue unless you want to make it an issue... If you are going to replace parts of your application let those parts be dynamically linked. There is no such thing as a "dll hell". All .dll's are loaded from your current working directory, your path, and the windows system directory, in that order. So, if you want to make sure the correct dll is loaded, keep a copy of it it in your app directory. If you can't handle having .so or .dll files, how can you handle having multiple .class files? It's essentially the same thing.

        • There is no such thing as a "dll hell". All .dll's are loaded from your current working directory, your path, and the windows system directory, in that order.

          Of course there is.

          What do you do if some application already sucked in version 1 of a dll, while another application needs (the incompatible) version 2 of that dll?

          Even using Java doesn't prevent from dll hell under Windows. I experienced exact this problem with the (native) Java driver of an OODB. :(

          Another obstacle is controlling the load paths, which is not always possible.

          For this, the .net "assemblies" will hopefully turn out to be major improvment.

          Regards,
          Marc

          • Of course there is.

            What do you do if some application already sucked in version 1 of a dll, while another application needs (the incompatible) version 2 of that dll?

            You put the dll in the same directory as the app that needs that version of the dll, that will solve your problem. Read my original post.

            • Yeah, cyborch is right. Read about it at LoadLibrary at MSDN: http://msdn.microsoft.com/library/default.asp?url= /library/en-us/dllproc/dll_1o8p.asp
              • Thanks for the link. It tells about the lookup procedure for dlls. So much so good.

                It is a bit unclear in regard to the term The directory from which the application loaded. In my case we talk about a set of Java jar files, moved over to the client box via Java Web Start. The application running is the javaw.exe in some installation directory. Over several stations it will pull in the jar that contains the reference to the native code which will trigger the LoadLibrary call. It could be that this LoadLibrary call is in some file different from the javaw.exe position.

                However my particular problem was a different one: It was not about not finding a dll but instead some other program already pulled in an older version of the dll now I'm busted.

                The kick is that it is a different program only from the perspective of the Java programmer and user (here a database inspector written in Java, there a Java Web Start application), but it is the same program from the perspective of Windows (the same javaw.exe that interprets both Java apps).

                To be more precise: somebody already opened a database inspector tool, this is a java program too, but it will trigger a LoadLibrary call to an older dll revision. Thus we have javaw.exe mapping in old.dll. Now I need to ran a Java program that needs to use new.dll, which would make the same javaw.exe to map to new.dll.

                As far as I understand, I can't do this, because it is the same app for windows.

                A solution would be to have a dedicated Java VM (with its own javaw.exe) that is used for Java Web Start execution. I used a different solution in that I created a Java based installer that does some detection work and pulls in an application part that references the same foo.dll hat was already pulled in, if.

                Is this DLL hell? I would say yes.

                Regards,
                Marc

                • Absolutely, this is a mess.

                  This is why I in my report recommend that you bundle your own JVM with your app. That way you can put any of your DLLs in the same directory as your javaw.exe, you are sure it is only started with your app, and you are sure that the JVM behaves exactly as during your own tests. Different JVM has different performance characteristics and take different non-standard parameters, so you can play safe only by bundling your own JVM.

                  BTW, I have heard several people complain that they couldn't get the Java webstart to work (as users), so I don't consider it stable enough for production use.

                  • This is why I in my report recommend that you bundle your own JVM with your app. That way you can put any of your DLLs in the same directory as your javaw.exe, you are sure it is only started with your app, and you are sure that the JVM behaves exactly as during your own tests.

                    Yes, that sounds like the right thing to do.

                    In fact the Java installer for use with Web Start I created to pull in matching DLLs was based on sample code by a poster from the JWS forum over at Sun, who first published how to roll your own JVM for Web Start installation. :)

                    Different JVM has different performance characteristics and take different non-standard parameters, so you can play safe only by bundling your own JVM.

                    I thought about this shortly, when 1.4 came out recently which triggered a couple of errors in our large application (one we had was a funny error regarding the Vector class, another remarkable one the fragility of 1.4's jpeg decoder which dies on jpegs with embedded thumbnail preview :) But I would probably (out of lazyness) just twiddle with the part of the jnlp descriptor, where one mentions the allowed JVMs, if I hadn't had this discussion with you guys. Hm, probably the most fruitful discussion I personally had on Slashdot for a long time. Something wrong here? :)

                    BTW, I have heard several people complain that they couldn't get the Java webstart to work (as users), so I don't consider it stable enough for production use.

                    No doubt, Java Web Start is not a ripe product. I grapple with it for several months now, and experienced many pitfalls with it. (Read the jnlp/JWS developer forum over at Sun for more :) It is frustrating to see such a good idea only finished for 90% or so.

                    I was surprised that Sun put it in 1.4, regarding the quirks which are not ironed out yet. On the other hand this will force them to repair it sooner or later.

                    Perhaps they had to simply issue it, regarding that .net assemblies and the global assembly cache look very similiar like JWS, if I'm reading their descriptions correctly.

                    From what I saw, Java Web Start was developed initially on the Solaris Plattform, and then ported to Windows in a hurry, without thinking too much if it was really possible to recreate the same under Windwows.

                    I believe this because some parts of the JNLP API (I mean the support services which should be offered by any JNLP client) like triggering a jar/resource transport into the JWS cache, or removing an item from the JWS cache do not seem to work properly under Windows. At least I didn't get them to work. The reason for their failure might be that files that are in use can be deleted under UNIX without problems, while they can't under Windows.

                    Further, the main two technical guys (Rene Schmidt who wrote the jnlp Specification, and another guy who seemed to do the implementation) seem to have vanished from Earth. They showed up on the jnlp discussion forum up to a certain point in time (about may 2001) also the last Java One article by these persons showed up around that time. Then nothing. Looks to me like they were taken away from this project, with the result of no major development happening anymore to the product (except small bug fixes).

                    Other madness includes dealing with native libs, where surprisingly Windows caused me less pain than Linux. I still don't know if a certain problem I had with Java3D distribution via JWS (which was possible for Windows), which involved having to resolve circular shared library dependencies, is really fixable or a principle problem.

                    Then we have the fact that Java Web Start is program useful for client boxes, and these are in 90% of the cases Windows machines. In certain for my company commercially interesting company environments, such boxes are administered well, which means that the user has no Administrator priviledges, in contrast to the typical home user.

                    Everything, including JWS installation, and the voodoo the Java app deployed via JWS might need, can't depend on having adimin rights there.

                    Unfortunateley the driver of the OODB we used, required admin rights for it's installation. (Which was unnecessary for a pure client setup - they required it because their install also included the case of server install, which would have added a Windows Service/daemon).

                    Others detected JWS dialing out to Sun, which should be a big no in a secured company environment.

                    Just a couple of items which showed a lack of real world usage of JWS. :)

                    Then we have the JWS cache update mechanism, which is often unpredictable to me. And a bloody "lazy/eager evaluation" behaviour and strange dependency tracking and ..

                    BUT, when JWS works, this is a damned comfortable and useful thing. It helped us much during inhouse development, when the non developers had to test things. People who don't know the intricacies of Java installation on their boxes and how make Java apps run from jars. They just want to click and launch.

                    Thanks again for discussing with me, I hope the insights won will help me to make our app more bulletproof!

                    Regards,
                    Marc

                    • lol. I am happy you found it useful. Personally I bundle the VM with my own projects and then let it be installed as part of the InstallShield procedure and put it in a sub directory of the main application. This way the end user will never know Java was used and Java will not interfere at all with the system itself. A recent game that used this approach was IL-2 Sturmovich (I haven't tried it myself) Feel free to mail me directly if you want discuss further. (jacob@marner.dk)

                • As far as I can see all your problems stem from the fact that you are using the javaw.exe to run your (non-managed) app as opposed to using some native code and running a native app. Using your own app would give you control over which .dlls are linked to your app and which .dlls aren't...

                  Alternatively you could manually load the library you wish to use a function in and call that very function. To that end you would need to call LoadLibrary() and GetProcAddress() in windows or dlopen() and dlsym() from libdl.so. I realize that this is native code, but that is often what it takes to achieve the results you want, and that is the reason why I would not choose Java for my game project.


                  • As far as I can see all your problems stem from the fact that you are using the javaw.exe to run your (non-managed) app as opposed to using some native code and running a native app. Using your own app would give you control over which .dlls are linked to your app and which .dlls aren't...

                    Alternatively you could manually load the library you wish to use a function in and call that very function. To that end you
                    would need to call LoadLibrary() and GetProcAddress() in windows or dlopen() and dlsym() from libdl.so. I realize that
                    this is native code, but that is often what it takes to achieve the results you want, and that is the reason why I would not
                    choose Java for my game project.
                    He was not talking about his own DLLs and not about a Java specific problem.

                    He was talking about having two different version of a third party class library and tool.

                    The third party library and tool was running in an old version. It was a Database Inspection Tool.

                    He had a Java program running using the new version of that class library.

                    Lets asume both used a dll called LIBRARY.dll.

                    As the Database Inspector allready had his LIBRARY.dll loaded the system refused to laod a second library with the same name. Instead of that the system linked the allready loaded library to the Java program.

                    Not java.exe or javaw.exe caused the problem: having LIBRARY.DLL loaded twice(oops, actualy loaded only once) causes the problem.

                    The only solution is to rename the libraries :-) newer apps should not dynamic link to libraries with the same name.
                    If so, the new library needs to be backward compatible to the new one. Then you replace during installation of the new app the old library and only the new one is installed in the system. Thats what Microsoft does(tries to do).

                    Regards,
                    angel'o'sphere
                    • As the Database Inspector allready had his LIBRARY.dll loaded the system refused to laod a second library with the same name. Instead of that the system linked the allready loaded library to the Java program.

                      We observed link errors with our app if someone used the db inspector tool before.

                      What I didn't realize before was, that this is not the same like running two different apps like a.exe and b.exe.

                      In fact this is java.exe interpreting a.class here and the same java.exe (in a different instance, which typically just means a different data segment for a new set of instance variables) interpreting b.class there.

                      Now a.class has a System.loadLibrary() call that pulls in old.dll while b.class has a call that pulls in new.dll. Thus Windows must map somehow old.dll into the javaw.exe process memory plus must map new.dll at the same to into javaw.exe process space. This won't work with just one (shared) javaw.exe code segement instance in memory, I guess.

                      I will try it tomorrow. :)

                    • The problem is not that you have two VMs using javaw.exe twice.

                      The problem is IMHO that old.dll and new.dll have the same name.

                      You can try to patch the class b.class(as you name it) and change the name of the library it loades.

                      Then you rename the loaded library accordingly.

                      Another possible error source: the loaded library itself loads further libraries and the true error is there.

                      Of course: custom class loaders do not help when it finaly comes to loading of native libs.

                      It would be interesting though if you could "overwrtite" the native laoding process, hu hom, have to dig into the docs, would not wonder if a classloader even can do that and I simply do not know it :-)

                      regards,
                      angel'o'sphere
                  • As far as I can see all your problems stem from the fact that you are using the javaw.exe to run your (non-managed) app as opposed to using some native code and running a native app.

                    Before the discussion with you guys here, I blamed the mess just on Windows. I thought once an instance of a dll is mapped into some process, no other process can map the same lib (same means, same interface signatures, the name of the dll is slightly different) but of different (incompatible) version successfully into its process memory space. I realized that is not true, because I don't have two different processes. I mistook the two different programs (db inspector, our JWS app) for different apps. But they are not. Both times the same Java interpreter (javaw.exe) is active. Which means one shared instance in the code segments and probably some kind of shared management of mapped in dlls, as an exe under Windows is really just a mapped in kind of dll, if I remember right. This is very likely the reason for my dll trouble.

                    If I use two different Java interpreters, eg by installing a second runtime (or better like it wa s suggested above, if I deploy the JWS app with its own Java interpreter). Then I have really two different/distinguished apps in memory, which should have not interference when loading the dlls.

                    About switching to native code: Too bad I have to use Java, and the available JWS version, even if it has bugs and undesirable behaviour. :)

                    While I have sources for them (this stuff is available under Sun Community License) I am not allowed to fix matters and distribute an "improved" version of the JRE and JWS to our clients. :(

                    That license issue is my personal problem with Java. I understand that it helped Sun to fight Microsoft for a certain degree, but for me this is a hinderance.

                    Sorry about the disgression from the original game topic of this discussion forum.


            • Of course there is.
              What do you do if some application already sucked in version 1 of a dll, while another application needs (the incompatible) version 2 of that dll?



              You put the dll in the same directory as the app that needs that version of the dll, that will solve your problem. Read my original post.

              Your original post is as wrong as this one and he tried to correct you.

              If a DLL is allready loaded there will no second one get loaded, the already loaded one is reused(so the one in the dircectory where the AP is is IGNORED!).
              If the first one is incompatible with your AP you are lost.

              Java however gives you with custome class loaders full control over your loaded classes. No problem to have the same class in endless different versions in your VM :-)

              Regards,
              angel'o'sphere
              • If a DLL is allready loaded there will no second one get loaded, the already loaded one is reused(so the one in the dircectory where the AP is is IGNORED!).

                You describe the case a.exe loads a.dll and b.exe loads a.dll (same name, but this a.dll containing incompatible code).

                Which won't work, because we end up with both a.exe and b.exe mapping in/sharing the first a.dll only.

                Java however gives you with custome class loaders full control over your loaded classes. No problem to have the same class in endless different versions in your VM :-)

                Funny enough this seems to turn out a kind of Java specific problem:

                We have two different Java apps, which means at some point two different Java classes, that explicitly contain a reference each to a natively implemented OODB driver.

                The thinking mistake was that these are not two different Windows apps. It is just one, the Java interpreter, interpreting two different Java apps.

          • Even using Java doesn't prevent from dll hell under Windows. I experienced exact this problem with the (native) Java driver of an OODB. :(

            I've started noticing "JRE Hell" when some applications install a new JRE and then turn it into the default on the PATH. (Oracle is infamous for this .. thanks Larry). Not quite as a bad as .dll hell, but annoying when it happens to our users.

  • I have several criticisms of the report.

    1. For each language, the report conflates the standard library with the language itself. Languages are grammar and semantics. Many specifications also describe aspects of the language run-time environment, but this is not part of the language proper.
    2. The paper makes little distinction among lanaguage/library implementations. This means that comparisons between Java and C++, especially when comparing performance, are not necessarily comparing apples to apples. Hand-waving implementational differences, especially between two different programming languages, is sloppy at best, especially when one may see vast differences in "performance" within a family of language implementations, e.g. in the Common Lisp world, the CLISP implementation (which compiles Lisp to byte codes running on a C-based VM) is said to have good bignum performance, but the CMUCL implementation (which compiles Lisp to assembly codes) is said to have superior fixnum and floating point performance.
    Ok, so with all this talk of performance, there is this really neat paper called "Optimization: Your Worst Enemy" [pgh.net]. It has an eye-catching title but it's really worth a read.
    • I failed to see more than one criticism, as #1 and #2 looked very similar to me.

      The idea that you can somehow separate language and run-time environment is of course partly true, but for most people not very realistic.

      Case in point: the standard C library. Most of the stuff here (with the exception of the varargs mechanism) is not part of the C language. Yet very few people would even consider using something entirely different, even though many (of the most used) parts of the standard C library really sucks (e.g. stdio is slow, malloc/free is more unreliable and slower than region-based memory management, there are plenty of functions that are not reentrant, etc...)

      Similarly, few people would develop java programs without at least the support of the classes in java.lang.*, java.util.*, java.io.*, java.net.*, java.awt.*, javax.swing.*, and so on. While it is possible (and probably easier than in the C case), most people just won't do it, for much the same reason as they wouldn't do it in C.

      And the reason for that is simple. You loose portability, you loose common knowledge, you end up with libraries less debugged and less trustworthy than the well-tried counterparts, you do a lot of unecessary work that could be better spent at your application, etc...

      Now, if this was a comparison of what was the "best language" (without qualification), then I would consider your critiscism appropriate. But it wasn't. This was a small survey to see whether it would be useful to write a game in java. And that meant using standard off-the-shelf compilers and libraries. If you wanted to implement your own run-time libraries, you could just as well implement your own language.

      As mentioned above, this wasn't a comparison of java vs. C++. It was a comparison of the run-time speed of MSVC++ 6.0SP5 versus Intel C++ 5.0 versus JDK 1.4.0 server versus JDK 1.4.0 client versus Excelsior JET Professional 2.1 versus IBM JDK 1.3.0, with an eye towards game-programming, and taking into account factors such as readability of the tweaked (optimized) code, developer time, portability and robustness of the different platforms. Considering that, it would be quite stupid to not take run-time libraries into account.

    • The criticisms;

      I considered splitting up the discussion so the library, language and their implementations was discussed seperately, but I decided against it in the end.

      The purpose of the language/library/implementation comparison of C++ is in chapter 5 to make it clear what differences the programmer has from a productivity point of view. Here it is irrelevant whether something is library or language. It is the whole that is interesting.

      And for the benchmarks. Here the library is purposefully attempted avoided (as possible). This is written on page 49:

      "If computational intensive libraries are used then the exact same libraries should be used in both cases. If this not possible then the libraries should not be used."

      So I am comparing apples with apples.

    • For each language, the report conflates the standard library with the language itself. Languages are grammar and semantics.

      Java the language is not too interesting (just a dumbed down C++ version, or sanitized C++ version depending on who you ask :)

      Of course one is comparing the Java 2 SDK (the language, the libs, the compiler, the hot spot vm, plus the available IDEs) to the Windows/MSVC++ combo.

  • Arkanae [happypenguin.com].

    Couldn't get it to work on my machine, though. Still, the screenshots look pretty. You have to figure that's the big hurdle...
  • Computers are not really taken advantage of nowadays. Weak compilers, very abstract languages, etc.
    Java will be a viable choice when the bytecode is run directly by commodity cpu-s.

    Actually a computer architecture would be interesting, that "thinks" in classes, objects and references.

    I think the faster computers are to run Java, the faster it is to just recompile your C or C++ code even on-the-fly...
    • Computers are not really taken advantage of nowadays.

      Well the Apple ][ people did amazing things with their weak hardware. But that was when hardware remained the same for a longer period. Today you can observe the same with the game consoles, which also show some impressive usage.

      Weak compilers,

      My impression was that compilers got cleverer, and need to get cleverer for the 64 bit PCs.

      Java will be a viable choice when the bytecode is run directly by commodity cpu-s.

      The interesting and unique bit about Java bytecode is not it being just intermediate code, but it being security proven intermediate code.

      Actually a computer architecture would be interesting, that "thinks" in classes, objects and references.

      Something like the old Lisp machines did?

  • You know, after getting suckered by sponsored research
    and publications for so many times, and made to
    buy into new tools and methedologies, I seem to
    have gotten a thick against such things.

    I was going to read the report, but there is something about its table of contents that
    suggests an element of bias, or a flame sparking troll at best.

    They make the BIG mistake of comparing two languages -again- and choosing a favorite.

    Next time -please- if you want to inform the public,
    or just want to push an agenda, please stand on
    your own and don't compare your NextGreatThing(TM)
    to an existing GreatThing(R).

    (I am self moderating, no +1 for this flame.)
    --
    • They make the BIG mistake of comparing two languages -again- and choosing a favorite.

      And as usual, many of the points made in favour of one or other betray a lack of understanding that disqualifies them from having an informed opinion anyway. It's sad but true that most critics have never taken the time to understand that which they criticise.

  • Hasn't Lisp already proven this? (Score:3, Interesting)

    by Jayson ( 2343 ) <jnordwick@gmaAAAil.com minus threevowels> on Saturday March 09, 2002 @05:03AM (#3134463)
    Since there have been games written mostly in Lisp already, doesn't this empirical proof extend to Java or other higher-level languages? I have seen comments such as "nobody wants to be first" and that there is "cultural baggage," but wouldn't Lisp's trail blazing really have been these new firsts and unloaded some of the cultural baggage?
    • Well, Lisp has a reputation for use in AI programming, so games programmers often think of it when considering scripting languages for enemy control - e.g. Abuse. (though, of course, there's nothing magic about Lisp that will make your enemies behave more intelligently, a dumb loop in lisp is still a dumb loop.)

      Java has a reputation as a rather pedestrian C++ variant (though due to its dynamic features, javais actually more like a cut down smalltalk with C++-like syntax), and really is a pretty boring and ordinary language. "21st Century COBOL" is how it's been treated in the corporate environment.

      • there's nothing magic about Lisp that will make your enemies behave more intelligently, a dumb loop in lisp is still a dumb loop

        LOL. A loop? If you find yourself writing a loop in Lisp, well... maybe it's time to stick to imperative languages until you've seen the functional light.
        • Almost true, but much truer of Scheme than Common Lisp.

          Common Lisp is emphatically not a purely functional language, its proponents will tell you it's "multiparadigm", and it's not all that unusual to see explicit loop constructs [xanalys.com] and other imperative stuff in production code. Sometimes the imperative form really is the more natural way to express something.

          CL really gives you the best of most worlds in programming.

          Scheme isn't purely functional either, but does tend to steer you toward functional programming more than CL, but largely through dropping stuff than Common Lisp programmers tend to find useful...

  • mobile phones (Score:3, Interesting)

    by jilles ( 20976 ) on Saturday March 09, 2002 @09:07AM (#3134680) Homepage
    Java gaming is going to happen, just not on the PC for the moment. Right now, mobile phones are being shipped that have a JVM on board. It will be a matter of time before someone figures out how to use that for games. The same applies to PDAs.

    These kind of platforms require the kind of safety and security Java offers. Particularly being unable to corrupt manually is a very nice feature since you typically don't reboot your phone.

    As for 3D gaming on the PC there's some stuff to consider. You have game engines, game code that uses these engines, standalone games and low level APIs such as directX or opengl. If you look at the quake and unreal engines (responsible for most of the succesful 3d games of the past four years) you will find that they include their own scripting languages in which most of the game functionality is implemented.

    In addition both John Carmack (quake) and Tim Sweeny (unreal) have considered using Java for that job in the past (way before stuff like hotspot compilers was around). For various reasons they chose not to. I recall Tim Sweeny saying in an interview he needed a more domain specific language than Java to script the objects in the game. Performance was not so much a concern (after all they ended up using a scriptlanguage).

    I don't believe we're going to see much Java games in the next few years. The existing game engines are simply to good and to mature to compete with. However do foresee a shift from the low level details of rendering 3D stuff, doing 3D sound, etc. to game functionality. Already many games just use third party engines for their games. Developing your own engine only makes sense nowadays if you're able to sell it to others. One engine for one game just isn't economically feasible anymore. Likely the game engines will continue to be written in C/C++. However its just a matter of time before there will be gameengines that can also expose their API to Java or .Net. Thus allowing gamedevelopers to use a higher level, less error prone language than C for the game functionality.
    • > Right now, mobile phones are being shipped that have a JVM on board. It will be a matter of time before someone figures out how to use that for games.

      It's already being done. See my reply http://slashdot.org/comments.pl?sid=29201&cid=3141 877

  • Embedded game languages (e.g. Unreal engine) (Score:3, Interesting)

    by smcv ( 529383 ) on Saturday March 09, 2002 @09:15AM (#3134688) Homepage

    Scripting languages embedded in C or C++ game engines, like Unrealscript in Epic's Unreal series, seem to provide a good compromise - many of the advantages of Java, but without the performance problems. (but then, I make Unreal Tournament mods, so perhaps I'm biased...)

    Epic Games' Unrealscript reference [epicgames.com] has some background on this. Some of the interesting bits:

    Why they didn't use Java:

    During the early development of UnrealScript, several major different programming paradigms were explored and discarded before arriving at the current incarnation. First, I researched using the Sun and Microsoft Java VM's for Windows as the basis of Unreal's scripting language. It turned out that Java offered no programming benefits over C/C++ in the Unreal context, added frustraging restrictions due to the lack of needed language features (such as operator overloading), and turned out to be unfathomably slow due to both the overhead of the VM task switch and the inefficiencies of the Java garbage collector in the case of a large object graph. Second, I based an early implementation of UnrealScript on a Visual Basic variant, which worked fine, but was less friendly to programmers accustomed to C/C++. The final decision to base UnrealScript on a C++/Java variant was based on the desire to map game-specific concepts onto the language definition itself, and the need for speed and familiarity. This turned out to be a good decision, as it has greatly simplified many aspects of the Unreal codebase.

    Game content and even third-party mods designed for Windows work perfectly on the Linux and MacOS ports of UT:

    UnrealScript is bytecode based: UnrealScript code is compiled into a series of bytecodes similar to p-code or the Java bytecodes. This makes UnrealScript platform-neutral; this porting the client and server components of Unreal to other platforms, i.e. the Macintosh or Unix, is straightforward, and all versions can interoperate easily by executing the same scripts.

    Why performance isn't always vital (my emphasis):

    UnrealScript is a slow language compared to C/C++. A typical C++ program runs at about 50 million base language instructions per second, while UnrealScript runs at about 2.5 million - a 20X performance hit. The programming philosophy behind all of our own script writing is this: Write scripts that are almost always idle. In other words, use UnrealScript only to handle the "interesting" events that you want to customize, not the rote tasks, like basic movement, which Unreal's physics code can handle for you. For example, when writing a projectile script, you typically write a HitWall(), Bounce(), and Touch() function describing what to do when key events happen. Thus 95% of the time, your projectile script isn't executing any code, and is just waiting for the physics code to notify it of an event. This is inherently very efficient. In our typical level,
    even though UnrealScript is comparably much slower than C++, UnrealScript execution time averages 5-10% of CPU time.
  • How easy is it in java to control the floating point settings of the FPU such as rounding and accuracy? 3D physics simulation is very sensitive to these settings.

    How can I write a game which is compatible with 3D glasses standards?

    Can I access 3D hardware functionality? Hardware lighting or multipass texturing?

    How much control do I have over the garbage collector? I don't want weird pauses happening at the wrong times.

    Can a java program change the screen resolution and color depth?

    How much control do I have over sound mixing? Can I use 3D sound?

    • Re:Java for games? (Score:2, Informative)

      by jacobmarner ( 565358 )
      When asking a question: "Can I do X in Java?" and X is something that requires access to some piece of hardware the answer is always that it is possible via JNI if not via the Java standard library. You should not feel limited by the Java standard libraries - if there is something you miss it is easily wrapped an accessed via JNI in a few minutes. If you can access it from C++, you can access it from Java. So for the specific questions: >> How easy is it in java to control the floating point settings of the FPU such as rounding and accuracy? 3D physics simulation is very sensitive to these settings. I don't know. >> How can I write a game which is compatible with 3D glasses standards? Already part of Java3D. Can be done via JNI. >> Can I access 3D hardware functionality? Hardware lighting or multipass texturing? Yes. >> How much control do I have over the garbage collector? I don't want weird pauses happening at the wrong times. Read the report page 37-38. >> Can a java program change the screen resolution and color depth? Yes - possibly only via JNI. My own game at www.rolemaker.dk does this. >> How much control do I have over sound mixing? Can I use 3D sound? All you want. Also via JNI. Wrapping a C++ for use in Java can be done in a few minutes so it is not something that should be considered a limitation.
    • Java3D [sun.com] is the answer to most of those questions.
  • You don't have to use the interpretation approach of the JVM. There are native compilers for Java, and they are used especially with embedded systems where you cannot allow interpretation overhead. Some native compilers allow you to turn off cycle-eating things like array bounds checking etc.

    The report PDF mentions them briefly on page 18, but adds that there are some "portability problems in practice". I'm not quite sure what that is supposed to mean - if there are errors in the executables generated by native compilers, it's a problem of that particular tool, not of the native executable approach in general.
    • >> I'm not quite sure what that is supposed to mean - Native code compilers is also discussed on page 39-40. An example is given on page 65. >> it's a problem of that particular tool, not of the native executable approach in general. Correct. This is what is meant. Jacob Marner

  • First, I do a fair amount of Java and C++ programming. Basically, if I want to get it done fast Java is a more forgiving runtime and language. If I need the program to run fast, it's C or C++. I've never done official tests, but Java always seems to take an order of magnitude more memory, and runs much slower.

    Maybe someone can explain to me, how Java could be faster than C++. He claims Java to be 0.7-4.5 slower that C++. Is a language compiled on the fly faster than one that's statically compiled before running? Is Java doing a better job of optimizing code?

    Most of the speed we seem to get from Java application servers seems to come from the fact the entire web pages are cashed in memory as servlets. Is the Java code doing a better job of caching data from images, sounds, etc. in ram?

    Please, enquiring minds want to know!

    Of course, if you could write games in Java, it wouldn't mean there would be a an avalanche of games. It would mean, however, that developers start writing more GUI apps as they get past the psychological part of the speed issue.

    • This is explained in section 6.3.2 on page 36-37 of the report.

    • Re:I'm very curious (Score:3, Interesting)

      by mvw ( 2916 )
      I've never done official tests, but Java always seems to take an order of magnitude more memory, and runs much slower.

      Memory waste seems to be a bigger problem in Java, then it is in C++. (Which in turn has a much worse performance impact than the usual suspect VM interpretation).

      I am not exactly sure why this is.

      • Is it because people have a garbage collector and thus they get more careless about memory cleanup?
      • Or is it because Java programs are on a higher abstraction level than C++ programs (which means more complex object hierarchies with much unfortunate temporary object creation/destruction)?

      Maybe someone can explain to me, how Java could be faster than C++.

      One argument is that a JVM like Hot Spot does dynamic compilation. The typical C/C++ code gets one once compiled. The resulting exe is hardly optimized after, even if you might take it to quite different execution environments.

      Code generation involves making assumptions about the execution environement and will result in certain influential decisions.

      A JVM like Hotspot however probes the present environment and will profile how the compiled code behaves, and will probably try improving matters during interpretation.

      This might lead to better and thus faster code than the static one, we are used too.

      I believe Intel's C/C++ compiler does a dynamic optimization at runtime too.

      Might be interesting to compare that one to Hotspot Java code. :)


    • Maybe someone can explain to me, how Java could be faster than C++. He claims Java to be 0.7-4.5 slower that C++. Is a language compiled on the fly faster than one that's statically compiled before running? Is Java doing a better job of optimizing code?

      Yes, on the fly compilation yields faster code. There is a researche project doen by HP, optimizing PA RISC code. The use a PA RISC code interpreter to observe and optimize PA RISC code on a PA RISC machine. The Interpreter is in raw cases up to twice as fast than pure native code.

      This is due the fact that everything is "observed" and tried to be tweaked. Cash misses, pipeline refills due to branches etc.

      The optimizer is able to "rewrite" the code. Its not jsut a removement of NOPs ore eliminatin of double jumps/branches.


      Most of the speed we seem to get from Java application servers seems to come from the fact the entire web pages are cashed in memory as servlets. Is the Java code doing a better job of caching data from images, sounds, etc. in ram?

      No, cashing of HTML fragments (or images) is language independend. It would be everywhere equally fast. A servelt is CODE, not data, which is cashed.

      A Java application server treats each servlet like a dynamic linked library. This means on the first request to a servlet it is loaded into memory and likely never released again (its code, so you usualy do not garbage collect it).

      If you use C++ you usualy use CGI, hence you create a new process for each request. In a Java application server you create a new thread, or more common, you reuse a thread from a thread pool.

      In Java multithreading is build into the language, same for garbage collection. In C++ a lot of programmers code defensive. That means they have to hughe code areas made single threaded(blocked by mutexes) just to be on the save side. Same for memory management: how many people use their own invented thread save memory management schema?
      A lot of time is wasted in making C++ "servelts" secure. A lot of such stuff is allready build into Java VM(and standard libraries).

      Also you may not forget: In a Servelt environment a lot of code is native. java.lang.* classes are mminly native. java.io.* also, java.network.* also.

      So you have not such much bytecode anyway.

      In a server environment you usualy use a Server VM, not a Client VM.

      A Server VM tries even harder to optimize code during observing its runtime behaviour.

      Next point is hardware. A Java Application server often is running on Sun hardware. (But other UNIX hardware has similar advantages) Sun hardware is excellent in multithreading. A JVM with native threading is excellent in handling the IO and database blocking and theading problems on Sun hardware and operating systems.

      If a standard C++ programmer likes to write a similar fast application he wastes effords in tackeling the threading problems allready solved in a VM.

      Regards,
      angel'o'sphere
  • First off, I am just trying to get my 2 cents in, I am a sophomore computer science student at the university of houston and just going on what I know. And trying to summarize the concept that almost everyone has brought up so far in some way.
    Programming languages are created for a purpose, to achieve a certain amount of ease in using key programming concepts. I'll just assume you know what the goals of Java and C++ are, and no surprise, neither was made with the core intent of creating video games. Video games are very complex; thanks to all the math involved in computer graphics, I would imagine that rocket science isnt far off. Java has advantages and C++ has its advantages as well. Theres no reason not to use both. For one thing in many projects most low level code that developers work with are the graphics/physics engines, or any other licensed technologies that they got from a different company. They can usually edit that code as they see fit, and work off of that. The question doesnt seem to be whether or not to use one over the other, but when to use each, and developers already ask themselves that question as it is. On a side note, the comment from John Carmack isnt entirely fair to the debate: I love his work but the guy is plan and simple a hermit and extremely intelligent, he would probably do an engine entirely java just for the challenge. I have no doubts it would be just as good as or better then the same work he would have done in C++.
  • I was wondering on everyone else's thoughts on this - besides the full-blown college report, you know. Grass-roots kinda stuff.

    If you can, keep away from the "My Perl blows your old Pascal away"-type posts, though.

Slashdot Top Deals

"Hello again, Peabody here..." -- Mister Peabody

Close