48 replies to this topic

[shadowomf]

I fear this is to far off topic. Hopefully not.

My hypothetical Java coder would not be "ignoring performance" (it's not like he's using bubble sort)

As mentioned before, I was assuming the developer knows what he's doing. By the way, bubble sort can sometimes be the right tool for the job e.g. for very small data sets (1-10 or something) it's simplicity can help it outperform more advanced algorithms.

And yes, I certainly do expect the user to buy new hardware, so that I can implement bigger and better features in my game instead of worrying about how fast it will run on October 4 2012 at 1:44 AM on current technology. Computers only get faster. Think in more than one dimension.

As far as I know most gamers that I would describe as casual gamers, don't buy new computers if they don't have to. And most of the time they are using them for many years.
If you do not depend on thoose extra sales, you are free to ignore them.

Note, currently I'm working on commercial software (not games) and most of the computers that I'm installing it on, are quite old. Even if computers are new, they are usually the cheap kind. However my impression so far is that private/personal computers are updated even less often.

Of course if you're developing the next Unreal or Crysis you know there are many gamers that will buy a new rig just to play your game. (Well Crytek still targeted DX9 instead of >=DX10... with Crysis 2.)

those who don't implicitly accept that some games may run slower by nature

Actually they don't take responsibility for slow software. For example, if someone complains that Outlook getting slower with each version, he is making MS responsible.
And he is right, if you have features that justify a higher system requirement that's one thing. But if you waste CPU cycles and can't show anything in return, don't be surprised if the user is thinking "Oh great another upgrade required because the developer is lazy".

he will benefit from fast development time

Well, if he had learned C/C++ from the beginning he would probably be faster using it than Java. At least for me this is the case.
Why does everybody, think it's faster/easier to use Java? I feel terrible when I have to use it and the lack of good tools doesn't help at all.

Okay, I was trying unsuccessful to find an article I read about how Java is a bad choice for teaching programming. But couldn't find it. Anyway, sometimes that extra difficulty can help making you a better programmer.

By an assembly guru. Well, I just don't think that's cost effective, that's all.

You're right it's not cost effective. However the thought of it is quite pleasing.
Well I like toying around with assembly and I'm glad it was part of my training. Even though I was never forced to use it in production (that would probably be a maintenance hell).

Just to make one thing clear, I think Java is a perfectly valid language choice. It's just my personal preference that if given the choice, I wouldn't choose it.

[Dunmord]

java its very powerfull and its better even than C and in some cases its better than C++

Better on what? It all depends on your target platform. Portability is easier in Java because of the virtual machine.

Java has been greatly optimized during the years, but you still get a performance hit (even small) because you have to run your code through the virtual machine. Java does use more memory than C++ because it is built upon objects. Every datatype in Java is an object, whereas in C++ native data types are not. Most C++ data types have a 1-1 correlation with assembler data types.

(C++) int - dd
(Java) int - dd + functions

The data part of the int in Java does translate to a data type in assembler, but you have functions that use memory.
To some games it may matter, to others it may not.

Last time I checked, C++ had much more mature game development tools than Java. You can even compare tools like Java 3D vs the C++ Irrlicht3D engine (both free).

[Oberon_Command]

Every datatype in Java is an object, whereas in C++ native data types are not. Most C++ data types have a 1-1 correlation with assembler data types.

(C++) int - dd
(Java) int - dd + functions

This is true in C#, but not Java. Java's "int" type is a primitive type and basically behaves like the "int" type in C++. In C#, "int" is basically syntactic sugar for the System.Single type, which is a value-type structure that represents an int. If you want to treat integers like objects in Java, you need to use the Integer class.

[CyberRascal]

Every datatype in Java is an object, whereas in C++ native data types are not. Most C++ data types have a 1-1 correlation with assembler data types.

(C++) int - dd
(Java) int - dd + functions

This is true in C#, but not Java. Java's "int" type is a primitive type and basically behaves like the "int" type in C++. In C#, "int" is basically syntactic sugar for the System.Single type, which is a value-type structure that represents an int. If you want to treat integers like objects in Java, you need to use the Integer class.

True, but misleading. It seems like you are saying that the implied performance hit when treating an int as an object applies to C# but not Java, but it's the other way around. Given that a primitive (or struct) in C# behaves like automatic variables in C++ (same in Java), there is no performance penalty in C#. However, in Java it is not possible to have arrays without indirection - you can only have arrays of the Integer object, which is a reference type. So basically for most intents and purposes it's more true that primitives are objects in Java than the other way around.

[Oberon_Command]

Every datatype in Java is an object, whereas in C++ native data types are not. Most C++ data types have a 1-1 correlation with assembler data types.

(C++) int - dd
(Java) int - dd + functions

This is true in C#, but not Java. Java's "int" type is a primitive type and basically behaves like the "int" type in C++. In C#, "int" is basically syntactic sugar for the System.Single type, which is a value-type structure that represents an int. If you want to treat integers like objects in Java, you need to use the Integer class.

True, but misleading. It seems like you are saying that the implied performance hit when treating an int as an object applies to C# but not Java, but it's the other way around.

I'm not saying anything of the sort. I'm pointing out facts. I'm not trying to make any implications here.

However, in Java it is not possible to have arrays without indirection - you can only have arrays of the Integer object, which is a reference type. So basically for most intents and purposes it's more true that primitives are objects in Java than the other way around.

Arrays of the primitive "int" type (as in the type "int[]") are perfectly valid in Java. Were you thinking of the collections libraries (like ArrayList, for instance), which don't support holding primitive types?

[CyberRascal]

Alright, just wanted to clarify

And yes indeed, I was speaking of the Java generics. Sorry about that.

[jbadams]

Last time I checked, C++ had much more mature game development tools than Java. You can even compare tools like Java 3D vs the C++ Irrlicht3D engine

That's not a great comparison though, as Java3D and Irrlicht aren't really meant to be equivalent or even particularly similar. I think jMonkeyEngine is probably a fairer comparison to Irrlicht, and it matches up pretty well. Something like OpenGL (although this is available to Java programmers via JOGL or LWJGL), Direct3d or perhaps at a stretch OGRE might be a fairer comparison to Java 3D.

You're actually right that there's less variety in the tools and libraries available to Java developers, but it's misleading to make an inaccurate comparison between things that were never intended to be equivalent, and although there's a bit less choice there are some good quality and well supported choices available.

[Anri]

Its surprisingly powerful. True, C++ is great for speed and flexibility, but Java is a good all-rounder. For 2D games, C++ isn't going to provide any more speed than Java, but getting into 3D, you might find C++ a better choice - but even then, it depends on how advanced you want your visuals to be: are you aiming for a Doom 3 level 3D engine or are you thinking of writing a 3D app like Maya or 3dsMax?

From experience, Java is certainly a good choice. At the end of the day, if there are only two heavy-weight languages its without a doubt C++ and Java. The only other language I would even consider would be C# but that is pretty much the MS version of Java, so learning Java you would know 90% of C# anyway. But anyway, you cannot go wrong with either C++ or Java.

[vladmihail]

Powerfull enought to kick ur ess!

[ATC]

Programming languages do not have any quality or property called "power"... So you'll never see anything like:

Language: C++
Horsepower: 700
Torque: 580lb-ft

There's simply no such thing...

Some languages perform differently from others, but there are no hard-set rules about performance either. Generally, languages compiled to machine code (native binary for the CPU) are faster than "JIT'ed" managed languages which are faster than interpreted languages. But there are even exceptions to this general rule... On quite a few occasions I've written and tested C/C++ and C# code side-by-side and seen the C# code out-perform the native code. There are various articles you can find online if you're more interested in language performance.

Any language that is Turing-complete (which is pretty much every programming language) is theoretically capable of calculating/simulating the entire history of the known universe; provided it runs on a system with unlimited memory. Therefore there's no reason you cannot create the same game in C, C++, Java, C#, Visual BASIC or assembly language.

Regards,

--ATC--

[Caburé]

Many functions of Java rely on the utilization of API that are not specilalized (like using BufferedImages and 2D GUI Api to draw sprites). Depending on which API you will use, your game may consume many more memory than necessary and go much slower than you would expect. The compiler+language+architeture are not a deal but how they are binded with some technologies(API) makes a HUGE difference.

I don't like to be forced to use (b & 0xff) for every byte to be able to know its integer value (to the hardware it donesn't need that operation but whenever the data need to be known or parsed it will have to be translated to more common values, if you like to use more known constants).

Data are not data.. you can't just cast things because they are encapsulated in round/closed solutions called classes... and they require you to use paths to deal with them: functions.. and java functions can be tedious since you may lose speed if you are heavy user of objects..

Java is not for speed. Is for portability and facilities(web). What you see as graphical results comparing Java and C/C++ is just the work of native graphics API/drivers receiving the necessary data at a constant rate. And the data received by OpenGL, for example, must match its requirements and I don't know if the java interface doesn't shift things before sending to the drivers.

Memory: you don't know how much memory an object will take and how worse it can get when you use third-party objects made for other kinds of solutions (not specialized in your case/solution) when you just use a bunch of them (Java is good using arraylists to store objects, not arrays - as records/structures..). In Java, all turns to facilitate the alignment in memory: I believe that most of the speed Java has is because the compiler hides what he does do store your, for example, stricted 3 byte data in 4 bytes in memory, wasting one byte just to have easy access, and how big is the speculation of the amount of memory needed for your JVM when you allocate memory: if you read a 30MB file, the JVM will request more than 80MB to the OS, trying to facilitate things for the programmer by speculation to the "future".. the flawless impression that Java does costs memory because when there is no more memory, your virtual machine/application just stalls and you have nothing more to do (even freeing objects won't make you able to continue, by how I use to face).
There is the garbage collector but it is more to a unspecialized guardian of presumable roads through what you may go or not, trying to let out of the oval circuit of memory reutilization the "stones" that your last lap had left and that you are maybe still using... lost threads sometimes are part of those.. but it is not easy to have a virtual clean and opened highway in front of you when you don't have ways to know in what speed you'll go (I mean dynamic memory utilization) because only the JVM knows where to store what you need.. and aligned in 4 bytes.. always.. per object (if you have a thousand objects of 3 bytes, you'll lose a thousand bytes if you store it in objects - if it is good or not, is up to you to know).

You may notice that if the project made in Java acts like a known tree, having all its growth process presumed and repeating it everytime, the JVM will not have so many issues about memory or the lack of speed that some facilitations that high level languages offer and that it is up to the programmer to make code that will slimly fit into the sharp requisites of API, working perfectly in the electric level of seam between the software conceptions and its overheads and the hardware immediate needs and characteristics but.. take care about what Java hides..

Edited by Caburé, 05 November 2012 - 07:28 PM.

[Aeramor]

I was once tasked with creating a game in java. Here is what I learned:

• Java is a terrible environment to work in. Debugging is atrocious and the tools for it are from the archaic at best and intentionally tortuous at worst. (compared to something like VS2010/2012).
• Speed wise it's incredibly slow but it's been mentioned several times here that for an indie team or a beginning developer you are not going to be pushing the envelope so don't worry about that.
• Java applets (so you can have a user play on/in a webpage instead of downloading your game first) means a lot of extra headaches not least of which is securing your assets.
• Java updates will constantly break your build and having the JDK on your computer will drive you insane.

That said, I don't think that speed should be your primary concern if you are just starting out in game development. C++ is much harder to develop and poorly written c is still going to be slow perhaps even slower with more memory leaks and crashes.
My recommendation for most new developers is C#. It's a SOLID language with incredibly robust tools, tons of support and an awesome community at the XNA forums. With some clever code you can attain perfectly reasonable speed even on heavy weight 3D applications. If your end goal is to be an engine developer somewhere like Epic or Rockstar games you need to be learning C++, otherwise pick a language that makes you comfortable with tools that you can understand.

Obviously you can tell I didn't personally like working in Java but then I'm an old fogie C developer. Hopefully you will take what I said with a grain of salt, evaluate the tools/language for yourself and make an informed decision you don't regret later.

[ATC]

@ Aeramor:

I agree with pretty much everything you said. I've never liked Java. I won't say language A sucks or language B is the greatest, but Java always seemed slow and unstable to me, whereas C# applications are snappy and responsive like C/C++ applications. I also agree that Java IDEs don't even hold a candle to Visual Studio; its really the best IDE for Windows available, and you can also of course use it to develop cross-platform applications.

However, I disagree with this:

If your end goal is to be an engine developer somewhere like Epic or Rockstar games you need to be learning C++ [...]

Yes, he does need to be learning C++... but not because it's the only path to being an engine developer, but because knowing C/C++ is an essential skill for any game programmer worth his salt! The 2000-teens are going to be the era of the managed engine. For years gamers have been accepting a lot of unstable code (consider Skyrim's tendency to CTD and lose textures at run-time) because applications/games are growing so large and complex that no mere mortal can manage all of its memory and resources. In this context C# and the CLR looks more appealing every day because its gains in memory efficiency, stability and type-safety are beginning to make it a more performant choice than native languages. This is precisely why my company is developing a managed engine in C# instead of using the traditional approach of C++...

Regards,

--ATC--

[MrDaaark]

So much BS in these threads. All biases and misinformation.

Java is a great language, and if you have to ask, then it is more than fast enough for anything you're currently able to produce. It will not produce the fastest executables possible, because that's not java's goal. The goal of the language is to produce a safe® executable that will that will run under a framework that can be ported to any hardware or operating system platform. Compile once, run anywhere. You don't write java programs to run directly on a target machine like you do in C/C++, you write them to run on the java platform.

Not sure why people bring graphics into this? The graphics card handles graphics. Even 2D sprite blitting was hardware accelerated back in the day, and you could store sprites in VRAM as runtime encoded sprites. The card would blit the sprite where you told it to because it was stored as a series of instructions. Just like now. You store your 3D models on the GPU card as a list of vertices, and then send the command to draw the model. The GPU always draws the model at the same speed, regardless of what language sent the command.

That stuff really came in handy when for the QBasic community. The language was slow, interpreted and had a 150kb memory limit ( I forget the specifics, that might have been for both code and data). But the community wrote a nice library that would talk to the hardware and the limits almost went away overnight. We could talk directly to the newer graphics cards, store all the sprites in VRAM, and simply tell the card to draw the sprite, instead of having QBasic do it manually one pixel at a time.

Naive and unexperienced posters always exaggerate how much slower any non C/C++ language is, and act like nothing can be done with them. Truth is, a lot of the games we play today are implemented entirely in scripting languages, some a lot slower and more bloated than Java. A lot of times, even with interpreted languages. The engines, written in C++ handle the system level tasks and the graphic calls, and then hand everything else off to scripting language to tell it what to do.

Way back in the late nineties, I was playing a complex action RPG that had a ton of stuff going on, tons of enemies, and it was all running on java scripts. Every mouse click, every particle, every enemy AI tick, etc... was all running an instance of a java program. All the in-game objects were defined as java classes. Everything concerning the game play was in java except the system level stuff, and it ran smooth and without any hiccups on CPUs that had less than 500mhz. You could open up the java sources and modify the whole game if you wanted. It was also a very modern, AAA title with models that had thousands of polygons each.

The first Quake and Unreal games were running their logic in slow interpreted languages. And Quake was targeting 90mhz Pentiums.

Someone said something about DCC programs like Max and Maya. A lot of the functionality in those programs is implemented as python scripts, and before that, it was all in MaxScript and MEL.

I tell you this because the bottle neck of video games are usually getting the graphics drawn. However, we have solved that problem a long time ago with specialized hardware that does the work so your CPU doesn't have to. The actual logic of most games uses up so little power and time that it's usually done in slower languages because the advantages of treating the gameplay as data outweigh the trivial speed gain of C code, and having to recompile everything every time you make a change.

So Java is more than good enough to make whatever you want to make with it. There is also a healthy demand for Java programmers in the job market. The entire Android app eco-system is all Java based programs (although, you can compile C code into libraries to call from your java apps). You may never need another language.

Now if only that stupid Java Windows runtime would stop being so annoying... ;) It wants to install a toolbar, and checks for updates even when I tell it not to. It even grays out it's own option to turn disable it.

[SimonForsman]

Its surprisingly powerful. True, C++ is great for speed and flexibility, but Java is a good all-rounder. For 2D games, C++ isn't going to provide any more speed than Java, but getting into 3D, you might find C++ a better choice - but even then, it depends on how advanced you want your visuals to be: are you aiming for a Doom 3 level 3D engine or are you thinking of writing a 3D app like Maya or 3dsMax?

From experience, Java is certainly a good choice. At the end of the day, if there are only two heavy-weight languages its without a doubt C++ and Java. The only other language I would even consider would be C# but that is pretty much the MS version of Java, so learning Java you would know 90% of C# anyway. But anyway, you cannot go wrong with either C++ or Java.

Actually, the visuals is the part least affected by the language/compiler/vm/runtime choice since it is (Assuming you use a modern 3D API) handled by the GPU. (There is a bit of additional overhead on the API calls themselves but it is fairly negligable unless you use something silly like OpenGL immediate mode).

I'd be far more worried about things like Physics(Allthough this can run on the GPU these days as well), While Java does perform the actual calculations just as fast as any other compiled language, with some exceptions since Java guarantees a minimum accuracy for all math operations(and the x86 CPUs doesn't meet all of them so you have to be careful there or things can slow down considerably) If you are writing a advanced game in Java you should read up on what Java operations the x86 will struggle with.
It also doesn't give you any low level control which does make it impossible to manually optimize things at a low level. (You can't write your own SIMD code for example and you can't fully control the memory layout), you get what Oracles JIT compiler gives you.

The biggest performance issue however is usually not with Java or the JVM itself, but rather with the practices Java encourages. (Excessive heap allocations/deallocations for example is one of the more common mistakes Java programmers tend to make and it results in memory fragmentation and increased cache misses (Which really kills performance).

[Anri]

Re: SimonForsman

I quite agree. The problem I've had in Java programming is with software rasterization, but who uses that in todays game development? Apart from perhaps raycasting or educational purposes, there isn't much point.

[Caburé]

Java offers ways to process pixels fast using BufferedImage. I've made this sample to test it (2D):




There is just one character and effects made straight to the pixels. I believe that, if things should have been spread through other objects, it could need a redesign to take advantage of architetural aspects as how loops and other predictions and metadata creation are made.

Edited by Caburé, 06 November 2012 - 09:09 AM.

[Caburé]

I am not saying java is bad or worse. It is different. I'll try to explain what I've got trying to use both OOP and needed software graphics simple operations as arraycopy and simple mean, additions/subtractions for bright/contrast (without hardware acceleration).


In Java, you can't control things at the hardware level (you can just prepare data to send to it): you just write and hope it to run at reasonable speed and Java doesn't have accurate timers - even a diference of time can't be assured to be real. Example:

// compares two moments, in miliseconds

long time1 = System.currentTimeMilis();

anObject.doThings();

long timeElapsedMs = System.currentTimeMilis() - time1;

System.out.println(timeElapsedMs);

//--------------

The time shown above can't be trusted to be exact about the time ran.

I was once trying to use math to make a sequence of events to become stable by skipping fixed periods of time based on a known variation and sleeps, shifting from slow to fast to make all run in the expected framerate and I could not make it work because the time difference always were over a limit of ˜8FPS (1000/8 = 120 ms) USING System.ArrayCopy (supposed to be the fastest way) - the job was to copy to a buffered image pixels the pixels of a source buffer, in the same format: Java schedules memory reallocation and garbage collection while in the loop and, for being so oriented to objects, I could never know when Java was bouncing the top amount of memory needed to keep the animation/reallocation (I tried to cut all to a fixed size copy/paste of memory) but for every single aspect, even to get current timedate you need a new object - new Date( ), for example. In the withins, Java creates many more objects. If you rely on that, your perfect Java written code may (may) become a powerful... resource eater.


If you need precision, you must rely on hardware. Relying on hardware makes that assumption about "compile once, run anywhere" worse: C/C++ can be used to run software that binds straight to the OS, without balances and fixed panorama about a basic architeture and reasonable speed conform that design. Reasonable speed conform the design is something that must be very good in Java Code for you to have a good result if you pretend to port applications.

Edited by Caburé, 08 November 2012 - 10:31 AM.

[PurpleAmethyst]

Does anyone ever get sick of the "How powerful is language X?" or "My language pwns yours"?

Better to ask "Can I get the job done in time with language X?". The answer is usually yes.

*yawn*

[tufflax]

One good thing about learning Java is that when you realize that Clojure is the best language ever you will be able to carry a few things over. (I don't mean to start a flame war, I just want more people to know about the absolute awesomeness that is Clojure.) Anything that Java does, Clojure does better. Programming in Clojure is pure bliss.

Honestly, if you are gonna go with Java, you might as well go with Clojure. Check it out:
Although the video does not do the language justice.

Edited by tufflax, 08 November 2012 - 09:20 AM.