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..
How powerful is Java?
I was once tasked with creating a game in java. Here is what I learned:
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.
- 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.
@ 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:
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--
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--
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(r) 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.
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(r) 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.
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).
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.
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.
Java offers ways to process pixels fast using BufferedImage. I've made this sample to test it (2D):
[media]http://www.youtube.com/watch?feature=player_detailpage&v=646NKDbbUxA[/media]
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.
[media]http://www.youtube.com/watch?feature=player_detailpage&v=646NKDbbUxA[/media]
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.
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.
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.
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*
Better to ask "Can I get the job done in time with language X?". The answer is usually yes.
*yawn*
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: [media]
Although the video does not do the language justice.
(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: [media]
[/media]
Although the video does not do the language justice.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
