• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Archived

This topic is now archived and is closed to further replies.

cwurts

java vs. C++

67 posts in this topic

Nobody has ever answered this question to my satisfaction. C++ is the standard for game development, but is there any good reason for this, other than circumstance? Is there anything java is lacking that would make it inappropriate for game development, and what would that be?
0

Share this post


Link to post
Share on other sites
most speed I believe simply due to the fact that c/c++ is lower level...

However Java is still very fast and supposedly easier to use and ideal for application development.
0

Share this post


Link to post
Share on other sites
Java forces you to use classes. C++ has it''s giant share of problems, but at least I can program however the hell I like.
0

Share this post


Link to post
Share on other sites
quote:
Is there anything java is lacking

Expressiveness and a clear vision. It amuses me that C++''s templates were poked at for being unfriendly syntax-wise, and now Java 1.5 sports generics with the same syntax. Sun strikes me as the IT world''s Hamlet: always changing its mind and bitching about the current circumstances instead of actually doing something.

Sun''s insistance on non-native GUI widgets kills the platform for desktop apps IMO. Sure, there are toolkits to do it, but it''s more a case of too little, too late.

That and what always bugged me is usually there is one way to do things in Java but it is always considered elegant(tm) because it is the only way.
0

Share this post


Link to post
Share on other sites
quote:
Original post by Johnson5001
Java is a much slower language than C/C++ because it''s an intepreted language.

Wrong. Java bytecode is compiled on the user''s machine Just-In-Time, theoretically allowing additional optimizations at runtime that are not possible at compile time.
0

Share this post


Link to post
Share on other sites
quote:
Original post by Johnson5001
Java is a much slower language than C/C++ because it''s an intepreted language. It also has a greater footprint (in all aspects) compared to C/C++ application, thus made it not suitable in game development. You could write games in Java, just that no one will play it.


It still amazes me that such blantant ignorance is still being spewed around, especially since JIT has been around for a while now.
0

Share this post


Link to post
Share on other sites
I think C++''s speed and expressiveness win the day. Mainly the former. I don''t see a whole lot of expressiveness in Quake, you know.
0

Share this post


Link to post
Share on other sites
Java and C# are NOT interpreted! JIT is not the same as interpreted. JIT is not executing bytecode. Learn your facts before spewing these lies again.
0

Share this post


Link to post
Share on other sites
JIT is a variation of interpreted languages, though it''s much closer to native code than pure interpretation.

And, yes, Java is still slower than C++ in the areas where it matters for game development. You don''t need me to tell you this, though - write two identical programs, optimizing as best as you can for each platform (or not optimizing at all, same effect) one in C++ and one in Java, and then tell me which one performs better.

Java is not designed for speed-critical applications. It''s designed for multi-platform ease of use.

Personally, I prefer C# to Java for new generation languages, but that''s just me. You may find that Java suits your needs better.
0

Share this post


Link to post
Share on other sites
quote:
Original post by cwurts
Nobody has ever answered this question to my satisfaction. C++ is the standard for game development, but is there any good reason for this, other than circumstance? Is there anything java is lacking that would make it inappropriate for game development, and what would that be?
1) These kinds of posts are against forum rules.

2) It depends what kind of game you are making. Web-based games are Java''s domain, but it just seems weird to make it take the place of C++ as far as commercial games. It''s just not what it was designed for. There is nothing to stop you from doing it, other than a small speed hit. And before anyone says anything different, yes, there probably will be one. Most of it comes from your lack of control over memory. A good Java programmer will be able to make this almost nothing though. Basically it comes down to which ever you are more proficient in.
0

Share this post


Link to post
Share on other sites
i think that until you come to the point when your program is actually running slow, you shouldnt be too worried. i was installing uru and noticed that it was installing a java virtual machine onto my hardrive. im assuming this means that the game was coded in java, sure didnt run slow. of course, most games still use c++. (before anyone decides to argue this, go to all the major game developers websites and check their job postings. you''ll see "c++" come up an aweful lot.)
0

Share this post


Link to post
Share on other sites
Many games today use java (or lua, or whatever) as a scripting language, since you can probably get something closer to 50-80% execution speed vs. C++, instead of the typical 5-20% with a pure bytecode approach.
0

Share this post


Link to post
Share on other sites
quote:
Original post by cwurts
Is there anything java is lacking that would make it inappropriate for game development, and what would that be?


For a PC game which is to be distributed as a boxed up CD on the retail shelves and is not intended to be ported to any consoles, no. Anything else is a maybe.

The first biggest problem with Java for games at present is related to target market. There is not at this time a port of Java to any console system, so this rules it out for a game that will target consoles.

The second limiting issue is JRE distribution. For a game delivered on CD this is no problem, as you can bundle the JRE with it. For web distributed games you are now either asking your potential customers to download the latest JRE separately, or bundling the JRE with the game download directly - moves which could affect sales.

Sun is doing a lot to get the JRE out there. Companies like Dell are installing the JRE on new computers they sell, there's an auto update now, etc... I'm fairly pessimistic on this sort of thing though, so the situation might be rosier than I think. I know Three Rings has been successful with YoHoHo! Puzzle Pirates. They distribute online with a bundled JRE. Other Java games, such as Alien Flux are having meager success being distributed via Webstart. I'm really interested in seeing how OddLabs does with their upcoming Tribal Trouble, as it is more hardcore than most of the Java games on the market now.

Those are the two biggest problems with Java game dev as I see it. On these forums, you'll see people rant about performance, how they are forced to use classes, how the garbage collector brings the framerate to a crawl, or how they don't need a language to hold their hands. I think it's fairly easy to separate the wheat from the chaff. To find out about the real issues that arise in Java game dev, head over to the javagaming.org forums and talk to people who are actually doing it.

[edited by - aldacron on June 13, 2004 1:33:51 AM]
0

Share this post


Link to post
Share on other sites
quote:

i think that until you come to the point when your program is actually running slow, you shouldnt be too worried.



Sorry, but no. While that''s certainly a valid response for optimization, it''s not exactly an easy task to completely rewrite your whole engine in another language once it''s been written. You need to choose a platform from the get go.

Yes, porting from C++ to java *CAN* be easy, but for someone who''d even ask a question like this, I can guarantee that it won''t be.
0

Share this post


Link to post
Share on other sites
I still think it's silly to say that because of JIT, Java is or can be faster than C++.

First off... there's a reason why games aren't being made in Java, and yes it has to do with speed/performance. Second, C++ is nessecarily faster than Java, even if you want to throw in JIT. I mean, you could make a virtual machine with JIT capabilities in C++, infact I'm pretty sure Sun's virtual machine is written in C or C++!

Third, have you ever seen a Java GUI? They have serious performance issues compared to an OS's native GUI.

Use Java because you want a language that is restrictively object oriented, neat, elegant, and don't want to have to worry about cross-platform issues. Don't let this JIT technology being able to allow incredibly small fragments of an algorithm execute 2 percent faster than its purely C++ counterpart fool you into thinking that JIT is the answer to Java's speed issues, because it's not. JIT is a nice and advanced feature, but it sure as hell doesn't compare to the incredibly impressive optimizations that a compiler like MSVC++ .NET provides.

[edited by - Kranar on June 13, 2004 3:31:31 AM]
0

Share this post


Link to post
Share on other sites
quote:
Original post by Kranar
I still think it''s silly to say that because of JIT, Java is or can be faster than C++.



Actually it''s not silly. Theoretically, runtime compilation should allow much better performance than current C/C++ optimizers. The compiler has more information available to make optimization decisions based upon runtime data. It''s a much more intelligent process. We aren''t there yet, but as the technology improves you might very well see Java and C# performance surpass C++.

quote:

First off... there''s a reason why games aren''t being made in Java, and yes it has to do with speed/performance.



Sorry, but no. There are several games being made in Java. Check out the links I posted earlier for examples. Of course, I''m sure you''re only referring to AAA, boxed, retail titles. You will see more of those in the near future, but as long as a shop wants to put a port on the console they won''t be using Java. And drop the performance myth already. It''s ancient history.

quote:

Third, have you ever seen a Java GUI? They have serious performance issues compared to an OS''s native GUI.



And all Koreans eat kimchi. You are generalizing, mate. AWT has been performant for years (it uses the native GUI). Ever used SWT? The only poor-performing standard Java GUI I''ve seen is Swing. Check out the 1.5 beta2 to see how it performs now.

quote:

Use Java because you want a language that is restrictively object oriented, neat, elegant, and don''t want to have to worry about cross-platform issues. Don''t let this JIT technology being able to allow incredibly small fragments of an algorithm execute 2 percent faster than its purely C++ counterpart fool you into thinking that JIT is the answer to Java''s speed issues, because it''s not. JIT is a nice and advanced feature, but it sure as hell doesn''t compare to the incredibly impressive optimizations that a compiler like MSVC++ .NET provides.



What happens when you couple the incredibly impressive optimizations that a compiler like MSVC++ .NET provides with the incredibly impressive optimizations that runtime compilers can provide? What do you think the MS .NET runtime JIT is all about?

JIT *is* one answer to Java''s performance "problems". I don''t know why you think it isn''t. JIT would even improve the performance of C++. How could it not?
0

Share this post


Link to post
Share on other sites
Well, actually JIT can't ever outperform "native" code. It can, at best, compile down into native code the same way as a normal compiler does. Doing this at runtime gives (theoretically) some advantage over statically compiled code. In practice, it doesn't, because it's pretty easy to determine where your bottlenecks are beforehand, and optimize around that. JIT solves a problem that doesn't really exist. It's a VERY useful tool when it comes to making a program that will run optimally on multiple platforms without requiring recompiling, though, as you can approach native speed without doing anything but update your VM. It's still faster to run an app optimized for each target platform, though (assuming you have a decent compiler and don't suck at programming).

Like I said before - write the same program in a JIT and in a non-JIT environment, and tell me which one runs faster (I'd recommend using C++ for this comparison, since you can do managed C++ -> CLR and get a fair comparison).

There's just far too much overhead involved with the process.

By the way - MSVC++ already does use JIT -- during debug mode.

JIT is the future, unquestionably. But it's not the present.

There is no performance "myth" about Java. Java is slower than C++. Do the programming yourself, it's the best way to be sure that it's a 'fair' comparison. I can already tell you what you'll discover though, because I've tried it myself. There is a LOT of overhead involved with the built in GC, the JIT compilation, and the rest.

Oh, and yes - there are games written in Java. None of them are very speed-critical games. You could also write these games in C# or VB (and at least you'd have easy integration of a first-class API, unlike the hacks like Java3D that exist for Java).

Many people don't seem to understand how JIT works. It *IS* bytecode. It's compiled "just in time" into appropriate machine code to give optimal performance during runtime. 99 times out of 100, this code is not on par with what would be generated by a native compiler during static compilation (how could it be? it's got fractions of a second to choose the best optimizations, whereas native compilers can spend as much time as they like compiling). It's not some magical panacea to solve all performance issues - you still have to program intelligently. With .net, you also have a healthy portion of your code precompiled so that it's already running in appropriate machine code for the platform (which is done because -gasp- it's faster than JIT!).

[edited by - Etnu on June 13, 2004 5:21:27 AM]
0

Share this post


Link to post
Share on other sites
quote:
Original post by Etnu
Well, actually JIT can''t ever outperform "native" code. It can, at best, compile down into native code the same way as a normal compiler does. Doing this at runtime gives (theoretically) some advantage over statically compiled code. In practice, it doesn''t, because it''s pretty easy to determine where your bottlenecks are beforehand, and optimize around that. JIT solves a problem that doesn''t really exist.



I''m inclined to disagree with you on this. There''s a big advantage to runtime compilation in the fact that the compiler has information available that a static compiler does not.

quote:

JIT is the future, unquestionably. But it''s not the present.



I agree with this, and said as much in my last post. Even so, Java specifically has seen significant gains in the last few years because of JIT.

quote:

There is no performance "myth" about Java. Java is slower than C++. Do the programming yourself, it''s the best way to be sure that it''s a ''fair'' comparison. I can already tell you what you''ll discover though, because I''ve tried it myself. There is a LOT of overhead involved with the built in GC, the JIT compilation, and the rest.



Yes, there very much is a performace myth about Java. I can''t count how many times I''ve read or heard people say "Java is too slow for this or that". That may have been true years ago, but it is no longer. I will not argue that Java is slower than C++, but I will argue that the difference is negligible.

I''ve been using Java for several years now. In that time, I''ve discovered a lot . And I will strongly disagree with you on the GC overhead. Just as there are things you should/shouldn''t do in C++ (avoiding temporary objects in overloaded operators, for example), there are things you should/shouldn''t do in Java. One of the things a Java programme should do is understand how the GC works. Another thing is GC profiling to find which of the available GCs work best with a particular app. It''s quite possible to code a game without seeing any GC stutters at all.

quote:

Oh, and yes - there are games written in Java. None of them are very speed-critical games. You could also write these games in C# or VB (and at least you''d have easy integration of a first-class API, unlike the hacks like Java3D that exist for Java).



That''s just nonsense. I think you''ll be surprised to see what comes down the pipe over the next couple of years, or even what is out there now if you take the time to look Some of the submissions for the Java Games Technology Contest should really open some eyes.

quote:

Many people don''t seem to understand how JIT works. It *IS* bytecode. It''s compiled "just in time" into appropriate machine code to give optimal performance during runtime. 99 times out of 100, this code is not on par with what would be generated by a native compiler during static compilation (how could it be? it''s got fractions of a second to choose the best optimizations, whereas native compilers can spend as much time as they like compiling). It''s not some magical panacea to solve all performance issues - you still have to program intelligently. With .net, you also have a healthy portion of your code precompiled so that it''s already running in appropriate machine code for the platform (which is done because -gasp- it''s faster than JIT!).


I''ll be the first to admit I''m no expert on runtime compilation, and that there is certainly room for improvement. But look how long it took for us to get to the current state of the art in static compilation. While the runtime compilation is certainly not a new idea, actively developed runtime compilers are still relatively young. Eventually, we''ll get to a point where this sort of discussion will be moot.

Java has its problems, yes. But they are not the problems that are commonly tossed about on these and other forums. I''m not quite yet willing to bet the bank on it for a self-published game simply because of the JRE distribution issue, but others are and some have been quite successful.
0

Share this post


Link to post
Share on other sites
J. P. Lewis gives wrote a practical article on all of this here. I think anyone who has doubts about Java performance should read it from top to bottom. You can find out more about Lewis'' works and reasearch (mostly in computer graphics) here.
0

Share this post


Link to post
Share on other sites
Java is nice, maybe tooooo structured, well its so structured it will give you a headache, c++ is older, its more manual, java does lots of things for you as it is very class based, as c++ doesn't have that much stuff built in,

for example its like opengl and direct3d, opengl and directx do the same thing, but opengl doesnt have everything done for you, you have to make it yourself where as direct3d contains alot of functions and methods, that help you out.

in the end java is slow and c++ is faster, java can make simple games, nice looking but simple,

where c++ can create nice looking and advanced


....I pretty good with Java as i am taught at college, but c++ i am playing with at home

edit:
whoever says java isnt slow, hasn't got the experience, tests and results they might do might say java is just as fast, but when you are using it , its so obvious,

[edited by - johnnyBravo on June 13, 2004 8:19:36 AM]
0

Share this post


Link to post
Share on other sites
Being class based is an advantage. It doesnt allow you to make simple hacks like c++ will. And as for speed *sigh* you can still get ~90% of the speed of c++, you are probably referring to swing,which *is* slow

For indie game dev. to e only problem with Java is that you have to distribute the JRE with it, and when selling online, people with 56k wont like that.

For professionals, C++ is used because it can be used on any platform. That includes all the consoles. Java is currently limited to only PC development right now, but who cares? Who here has an XDK?
0

Share this post


Link to post
Share on other sites
quote:
Original post by johnnyBravo
whoever says java isnt slow, hasn''t got the experience, tests and results they might do might say java is just as fast, but when you are using it , its so obvious,


And you, of course, are speaking from vast experience:

quote:
Original post by johnnyBravo
....I pretty good with Java as i am taught at college,



Can you tell me how much overhead is associated with a Java class? Which garbage collector does the Sun VM use by default? Under what circumstances will the compiler inline a function call? What is the purpose of soft/weak/phantom references and when should they be used?

I don''t want to get into a flame war over this, as it''s a waste of time and bandwidth. But really, take a look at the link I posted above and read it from top to bottom for a candid look at Java performance. And please don''t insult my intelligence.
0

Share this post


Link to post
Share on other sites
quote:
Original post by JasonC
Being class based is an advantage. It doesnt allow you to make simple hacks like c++ will.


Not really, not all problems are worth a class system to sort them out where as others map more naturally to classes, giving the programmer a choice as to which to use is better imo.

and ''simple hacks'' are often all thats needed to get a job done, just something quick and dirty to test something out... although in that case even C++ might not be the best choice, but even so its probably a good thing to still allow it (plus one mans ''hack'' is another mans solution)

0

Share this post


Link to post
Share on other sites
quote:
Original post by _the_phantom_
quote:
Original post by JasonC
Being class based is an advantage. It doesnt allow you to make simple hacks like c++ will.


Not really, not all problems are worth a class system to sort them out where as others map more naturally to classes, giving the programmer a choice as to which to use is better imo.

A good programmer knows how to choose the proper tool. To claim that Java is bad because it's class-based is like saying that water sucks becuse it's wet. Java is OOP only and class based. Use it in areas where that attribute is an advantage and user other languages in other areas. Judge Java for what it tries to be, not for what you would like it to be.



There's no place like 127.0.0.1


[edited by - rohde on June 13, 2004 9:15:42 AM]

[edited by - rohde on June 13, 2004 9:16:12 AM]
0

Share this post


Link to post
Share on other sites