We Keep Coding

Switching from AndEngine to libgdx - what to know? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I've been testing with AndEngine for months, but still haven't produced any game prototypes. There are few reasons why I want to switch to libgdx:
- AndEngine is using libgdx's INI wrapper for Box2d, but updates reach Andengine slowly
- I'm primarily targeting Android, but having option for easy porting to other platforms could come handy
- Documentation! AndEngine has absolutely no documentation, except for examples.
- I would like to get as high performance as possible and that seems easier on libgdx.
Few things I am concerned about libgdx is that I will need to write lower level code and that development for full game will take longer? But then again, sometimes I lost few days to understand how some parts of AndEngine work, so is it possible that I'll even write code faster with libgdx since it's fully documented?
What should I be aware about libgdx before switching? What is main difference when coding game and designing code?

You should be aware of the following things:
It is more performant, thats a fact and widely known. Libgdx uses
native code for the more difficult tasks.
Development on it is very fast, I dont get why (some) people say it
takes a lot of lines to do simple tasks, thats simply not true. The
library is very high level with the possibility of programming as
low level as you would need. Especially the ability to test on
desktop immediately, instead of waiting for the app to deploy to an
android device or worse... the emulator. That makes the development
time way faster.
The library gives a lot of freedom, you can make the things as you
want it. For example I made a template that I use for every new
game, that makes things even faster for me.
You dont have to know opengl, androidsdk or lwjgl, actually you just
need to know the abstractions of the library. But you can make
platform specific code if needed. And thats well documented.
complementing P.T. point, libgdx has a wrapper for box2d physics and
bullet (3d) physics which are pretty easy to use (except bullet :S
nah kidding). And I would say, the new 3d api is almost complete,
not much will change for the next stable release, I even read on irc
that it is pretty much done. I use it and can tell you its very easy
to use.
In conclusion, Libgdx is a very fast library to develop on. Its very performant, and complete. Has a good and helping community, plus great documentation. I would recommend you to change :)

Both P.T. and Lestat make very good points in their answers. But for me, I think there is just one thing that you need to know about libgdx, which is simply that libgdx is a toolkit not an engine or framework. This one fact means that you are not locked in to a particular way of doing things. If you want a micro-framework, write one with libgdx. If you want to write "Unity 2D", write it with libgdx. If you want to put everything in one file, throwing object oriented principles to the wind, you can do that with libgdx.
It helps that it is well documented.
It helps that it is fast.
It helps that it has a strong, knowledgeable community.
It helps that the source code is available and is well-written.
It helps that it comes with examples.
It helps that it is a platform abstraction layer so the same code will run on multiple platforms.
It helps that it is actively developed.
But fundamentally it is a toolkit, albeit an excellent one. What you choose to do with that toolkit is up to you.

If you're having problems finishing prototypes, I would concentrate on the usability of your tools (over performance, for example) to produce prototypes. So, the speed of updates to Box2d shouldn't be important (its in a good enough state). The ability to do development on your desktop should be important (build/test time is much quicker) without an Android device in the loop. Documentation and examples should be very important. High performance does not matter on a prototype that is never completed. Worry about that later. (Goal #1 should be completing something.)
Libgdx has a broad set of libraries and wrappers, mostly around graphical APIs (e.g., Scene2d, or SpriteBatch or the TiledMap infrastructure). There is a 3d API, but it is still moving pretty quickly, and not yet a stable place to develop on. I want to say that it doesn't have a lot of "gamey" abstractions (though it does have some), but I really don't have enough experience with other higher-level libraries to compare.
Instead of trading your current tool's short comings and pitfalls for a new tool's shortcomings and pitfalls, you are probably better off sticking with the tool you know.

Java High Graphics 3D Games? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Why are there no "High Graphics 3D games" made with Java on the market? Isn't Java a good option? And why so? The only big game i've seen is basically Minecraft, and there can't be a large amount of polygons and lighting/physics-engines in that one. Still a relatively good pc is needed? There are games incredibly more graphics heavy than Minecraft and stills runs faster. I suppose Java "wastes" resources. Anyway, the question is: Is it possible to make good graphics application with Java, or why not.

The game development world is a funny one: On one hand, they're often
quick to accept new ideas, on the other hand, they're still in the
stone age.
The truth is, there's rarely that much incentive in switching to
.NET/Java/anything other than C/C++.
Most game companies license parts of the game engine from other
companies. These parts are written in C++, and although you might have
access to the source so you could port it, that takes a lot of effort
(and of course, the license needs to allow it).
Also, a lot of legacy code already exists in C++. If code from
previous projects can be reused (say, if you're writing a sequel),
that counts even more in favor of sticking with the same language,
instead of rewriting it in a new language (more so since you'll likely
reintroduce a ton of bugs which you'll need to spend time ironing out.
Finally, it's rare for games to be written in 100% C++ anyway - a lot
is done using scripting languages, whether they're custom or just
integrating an existing languages (Lua being one of the more popular
ones these days).
As far as garbage collection is concerned, that can be a bit of a
problem. The problem is not so much that it exists, it's more how it
works - the garbage collector MUST be non-blocking (or at least be
guaranteed to only block very briefly), since it's simply unacceptable
to have the game freeze for 10 seconds while it scans all the
allocated memory to see what can be freed. I know Java tends to choke
quite a bit in GC'ing when it's close to running out of memory (and
for some games out there, it will).
You're also a bit more restricted in what you can do: you can't fully
exploit the hardware due to the overhead of the runtime. Imagine
Crysis being written in Java... even if that's the only visible
difference, it just wouldn't be the same (I'm also pretty sure you'd
need a Core i7 to run it.).
This doesn't mean these languages don't have their place in game
development - and no, I'm not just referring to tool programming. For
most games, you don't need that extra bit of performance you get from
C++, including 3D games, and if you're writing it all from scratch, it
can make perfect sense to use something like XNA - in fact, there's a
good chance it will.
As far as commercial games are concerned - does RuneScape count?
That may well be the most succesful Java game out there.
Source: Why are only a few video games written in Java?

Java vs. C++ for building a GUI which has a C++ backend [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I currently have a C++ backend that I need to connect with a GUI, and since I've never built a GUI before, I was confused on where to start.
I'm comfortable writing code in C++ and Java, so I'd prefer my GUI to be in one of those languages. Also, the GUI has to be reasonably OS independent over Windows and Linux (and hopefully, hence Macs).
Now I understand that if I use Java to do it, I'll need some wrappers to do it - but I've also heard (strictly second hand) that writing a GUI in C++ is a pain.
I don't want to rewrite too much of my backend code in Java (who does??) and I was hoping for input on:
Does either language offer serious advantages/disadvantages compared to the other?
How serious is the wrapping issue, and how much rewriting would come in if I used Java.
Are there any specific resources I should look at that people think would be relevant?
Thanks and Cheers All :)

Have a look at Qt.
In my experience communicating between two different language runtimes is always challenging. If you have a non-trivial application to build the following often pose challenges:-
Error Handling.
Memory Management.
Multithreading and Synchronization
Semantics.
Apart from increasing one level of indirection due to wrappers, it requires a lot of thinking like circumstances where you need to pass data structures across GUI and backend etc.
For example:- Consider passing a Java String from GUI to backend C++.
Essentially, we have to extract the characters from a Java String object and make them available to the C++ developer without leaking the memory which holds them. This is an example of a basic problem (there are other aspects too like the encoding in which the characters are to be returned).

You say you already know C++ and Java, and that you never did a GUI before. That means:
no matter if you go for a Java GUI or a C++ GUI, you will need to learn how to handle the GUI framework
if you chose Java, you also need to learn how to interface between the two languages
So staying in C++ saves you one thing to learn. Well, it's always a good idea to learn something, but might be a bad idea to learn two new concepts at the same time. Anyway, the learning might be the smaller burden, I guess there is a lot of actual work involed, even when you use tools like SWIG.
You might want to know if writing a GUI in Java or doing it in C++ is easier. It depends on the chosen Framework. For Java, you have AWT and Swing which are part of the default Java distribution, and then there is SWT which is used by Eclipse, for example. For C++, there are many toolkits, with Qt, GTK and wxWidgets being the most popular ones, and all three support every major platform. Most of those "C++" GUI toolkits also have a Java binding or even a Java port, so you could use them with Java as well.
So far I've used Swing, Qt and a few others which don't help in your situation (The UI thingy that came with Borland C++ Builder and WinForms on .NET). Basically, the concepts are the same for all those frameworks, and I found none of them being harder or easier than the other. The only exception maybe Java, because I never got those LayoutManagers to work, even though the other toolkits have equivalents to LayoutManagers that are easy to master. But maybe thats just me.
People also will tell you that Java GUIs are always ugly and don't fit the host system. Well, most Java GUIs really are, but IMHO thats not because of Java, but because of bad programming. It takes two lines of code to let a Swing app adapt to the look and feel of the OS, and most programmers simply don't put enough effort into their Java GUIs to copy and paste those two lines... you can imagine how much they care about the rest of their GUI design.
For your current situation, I would recommend a C++ GUI, but if you know how your future plans look like, and if you know you will doing Java GUIs for the rest of your life, then it's probably ok to start that now and take the extra effort of .
And if you chose C++ for the GUI, people will tell you all kind of things to pull you in any direction. All of the three big portable frameworks have their pros and their cons, but I don't believe there is any single best or worst one among them. I'd recommend Qt simply because I already used it - but if I'd happten to have used GTK or wxWidgets instead, I'd probably suggest that.

Depending on your needs, a simple web interface might be the simplest when you have no existing frontend code. Embed a tiny web server in your application and open a browser on "http://localhost:12345" (or what port you end up using).

I can't say much about coupling Java and C++, but I suggest you have a look at Qt.
It's a C++ library for a lot of things, like file and network access, but it's most famous for GUI development. It also has a nice IDE were you can build your GUI with drag-and-drop.
I would also say that Qt is as OS-agnostic as it gets for GUI libraries.

Writing a GUI in C++ is no more of a pain than doing it in Java.
There are numerous cross-platform GUI libraries. GTK, gtk--, FoX, WX, etc. I would not recommend Qt since it's not really C++ (uses an extended version of the language requiring a special preprocessor before compilation). Plus it costs a fortune if you don't want to give away your product.
BTW, that's not how the word "hence" is used.

You did not mention the richness of the interaction between front and back ends, which would weight the importance of the existing language in your decision.
I've worked with Qt, Swing and SWT, and typically used both C++ and Java code with all of these toolkits. The interaction between languages can add additional cost/risk. However, sometimes that cost is warranted given other benefits.
If for any reason you choose a Java front end, look at JNA and SWIG.

Let's all be honest here. C++ just ain't on the map when it comes to portable GUIs.
Java has a consistent, portable, widely used, thoroughly documented, mature GUI toolkit. C++ has a bunch of half-assed OSS libraries that barely work, none are truly portable, plus some expensive commercial libraries that don't work on all targets they claim to, work spotty on the remaining targets, and invert control so that you are stuck in their weird framework.
Unless you need C++ for other reasons (of which there are plenty), choose Java for the GUI. The cross-over coding is trivial for someone who knows both languages, but it can get messy to manage, so you'll want to minimize the native interface as best you can. My advice here is to make a pact with your team that you will never attempt to hold pointers (or references) across the interface. It just gets messier if you do, and no debugger can save you when the lines get tangled. Instead, use integer or string keys and pass them across the native interface.

How about eclipse? Looks good and performs well on all platforms. My guess is most of eclipse is Java.

Why you don't you learn native C++ GUI like WINAPI or X11? Then you can make console software to compatible one of them like winehq, cygwin or other open sources compatibility or emulated software, since you never developed GUI on C++. Don't go for Java because it uses much more RAM. Of course, unless you have lots of RAM. For example, Eclipse (which is coded in Java) can use 500mb of RAM when running with no project opened.

Wrapping is not rewriting, it's just an adapter to make both languages meet. It is straight-forward
As you don't seem to be fixed on a language, I would choose a .NET Gui (With C++ CLR) you'll have a GUI that is machine independent and you can easily communicate with your existing code.
For beginners WinForms is maybe easier, but try to use WPF, it's the most modern variant for GUI development in the .NET world.
Personnally I would use C#/.NET for the GUI and use a C++ CLR wrapper DLL. But it is not the only solution.
Under Linux, the best .NET implementation is MONO. For all WinForms apps I have developped (they are not the craziest ones), they ran without change. With C++/Qt you will have to recompile for each target OS.

Do not use Java for creating GUIs unless platform independence is a must. The user experience will be sluggish and interoperability to C++ will be a pain.
For creating native GUI in C++, you can either use GTKmm along with a library like Boost or QT. Additionally, these libraries are available for most platforms (GNU/Linux, Windows, OS X) so your application can be recompiled anywhere.
edit: use GLADE for quickly creating GUI and fill in the signal slots with C++ code in GTKmm.

Game Programming as Hobby, should I use Java or C++ [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Presently, i am learning Java from the book The Art and Science of Java and following Standford's Programming Methodology Course.
I would like to do game programming, but only as a hobby.
I was thinking, would Java be a good choice or is C++ the defacto in game programming.

Since you are learning Java i would recommend that you stick to it.
If you are only developing games for fun, it won't really matter what language you use.

That depends, do you want to learn more about C++? Do you need to know? There's still OpenGL libraries in Java that are available, and the concepts would essentially be the same regardless of what language you work in. If it's just for a hobby then I can't see anything wrong with working in Java. In terms of speed however, lower-level languages are prefered.

Either would be fine. For a hobby, they both have pretty good low-level support for graphics etc, and both also have pretty good higher-level libraries for games (jMonkey engine, SDL, SFML, Ogre and many more).
You could also consider other languages too. Python has SDL bindings called PyGame. C# has the XNA framework which has several books published for it now to help learning the framework. SFML has bindings for C++, C, D, Ruby and I think Python. All of these are then suitable for creating games in. Just pick a language and off you go.

If you ask me, neither Java or C++ are fun languages. Both of them have a number of advantages but if you're doing it for fun and don't have deadlines, I would seek out a language that's more fun. Like Python, or something similar.

If you want to make games you really need a game platform as well as a language, otherwise you will spend all your time solving basic problems like how to draw a sprite to the screen, rather than concentrating on building a fun game.
Great choices for hobby games development are:
Microft's XNA platform with C# language
Adobe's Flash with ActionScript language
Sun's JavaFX platform with JavaFX script language
Unity3D with C# language
Ogre with C++ language

You can write games using both languages but I think you should really try C++. There are far more high-level libraries and game engines written in C++ than Java so it would be easier to find one that suits your needs. Not to mention that a lot of older games have been open sourced and you can freely download them and study the code. You can guess what language they're using ;)
Also you'll find a lot more tutorials and books that teach game programming using C/C++.
No matter what you choose in the end, have fun writing your games :)

If you go with Java, I recommend Computer Graphics for Java Programmers, by Leen Ammeraal.
If you were developing commercial games you would be using libraries rather than implementing these algorithms yourself, but it's easier once you know the fundamentals, which you can learn from a book like this one.
I once wrote a software renderer for a DOOM clone in Java, and having this book for reference helped a lot.

C++ is THE defacto language not only for game development but for pretty much everything else, including the browser you are using along with the OS it runs on.
So if you are considering ever getting serious with programming C/C++ should be top at your list.
As for speed C++ IS generally fast than Java.
Why generally?Well, the truth is that C++ is faster than Java, is faster than pretty much everything else actually, but sometimes C++ code can be poorly written and Java may prevent beginners to make some mistakes resulting in many of the claims that Java is as fast as C++, there are even claims that Python/Psyco are as fast as C++ and faster than Java.
Keep in mind that no program written for a framework (Java, .NET, VB, etc) will ever run faster than a program that runs on a lower level (direct on the OS or even the hardware) like C/C++, ASM, Pascal and so on.
Take a look at this:
Poorly written C++ half the speed of Java, properly written is much faster
At the end of the day you should go with the language that you feel more comfortable with, remember that python is enterprise ready, commercial, stable, great for beginners, awesome to use on "Web 2.0" projects not to mention that is a lot of fun too.

Java - I'd recommend sticking to one and getting good at it. The ideas remain the same, and as you learn more about a single language, you'll begin to learn about the drawbacks and advantages that are prevalent in many of the programming methodologies and languages today.

Even if you never intend to get into professional game development there is one big advantage to C++, which is that you have a lot more resources available. There are more books, more tutorials online, more open source examples to look at and more people who will be able to answer your questions on sites like gamedev.net.

I have developed a couple of small games in both C++ and Java and I would select C++ everytime. It gives you the low level control which you just dont get with java. But games development is a whole different beast. So if you are looking to learn games developement start in something you are comofrtable with

If you think you may one day want to work in the industry, you should learn C++. C++ is used to make pretty much all commercial games that run on PC/xbox/ps3. I assume wii is the same but don't know 100%, I never worked on wii.
The games studio I used to work at (before it got shut down) used C++ for the game (small parts used C and assembler) and was starting to use C# for tools.
If it will only ever be a hobby, then it doesn't really matter what language you use.

I would suggest to try Haaf's Game Engine for C. It is very very simple 2D engine with good documentation, tutorials and examples, runs on Windows 98 and above and it is ABSOLUTELY free even for commercial usage!
If you're completely new to game development, it's right for you IMHO.

Only a hobby? If you're using Java then Java. But first, what are you programming, 2-D or 3-D games? Java does both, and it's my game programing language, but I'm doing only 2-D programs. C++ is the defacto standard for serious game programming, especially commercial games.
Java has a great IDE called Eclipse, which, to me, is worth doing Java all by itself...Eclipse rocks! And it's free.
C# - no. Way too Microsoft dependent.
Btw, Java will work as an applet and as an application if you plan it well, the application runnable on all three platforms...
So, think about it. Low investment, high quality tools, cross-platform. If you decide to get into C++, then that's okay too. At least you will have wet your toes for free...
;-)

Language defines target platform and public. Both Java and C++ have advantages and disadvantages. You will use same architectures and algorithms on any platform. If you know how to write a game in C++ it takes a little to write game in java (2 weeks for me http://madeinsoviets.net/).
Start learning game programming with C++ and some easy game engine (Ogre3D, irrlight) - much more information and tutorials.

Old topic but since people still read this i want to add my 2c since its unique
to this post.
Stick with java, its a great way to make games over c++ if your going to do it as a hobby
and by yourself for these 2 reasons.
10x less coding for the same results (albeit it runs about 5x
slower)
Android games, even mediocre ones will sell (a buck each) on the
marketplace. if you sell even one your going to feel huge pride!
(also java doesnt slow down over C++ on android because its JVM is
unique and runs against the API directly accessing hardware, which
is fantastic!)

If you are just doing it as a hobby, it probably doesn't matter. Just use whatever you are most comfortable so you can get into the swing of game programming. Once you get better, you might like to figure out what is the "best" language.

I would definitely suggest C++ if your intention is general game programming. Of course, if you want to develop for a mobile platform such as Nokia and Ericsson then Java might be a good idea.
But if it is for general desktop gaming then definitely C++. If you want to deploy games over the net then flash might also be a good idea.

If you're planning to enter the industry (or maybe a day start to sell your game yourself), then you have to learn C++.
Java or C# are good choice to get to the point of creating game without worrying much about the machine (memory and speed). That's recommended for beginner, but I would personally start directly with C++.

If you're looking into game programming then C++ is the way to go. Sure Java will be good for certain games, but C++ is so much faster.
I've coded in Java before, and then started coding in C++. The time I've spent coding in C++ made me understand certain things that were heavily simplified in Java.
Depending on how much experience you have programming, I'd suggest to learn the basics of Java and then move on to C++.

If you start with Java, I recommend this book Physics for Game Programmers

In general, C++ is for real games.
Java has always been slow for me, whatever platform or program I use.
C# is better than Java, but not as good as C++.
Yes, there are exceptions, but the fact that they are so notable rather proves that C++ is just the way to go unless you really know what you're doing.

C vs. Java for game programming [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I understand that C++ is generally considered better than Java for games (at least larger-scale games). Why is this?
What is keeping Java from being competitive in this field? Which reasons against using Java for game programming have the most basis, and which ones are myths?
EDIT: Am a bit unfamiliar with C/C++, and did not think to differentiate between the two at line 1 >.<

The reason Java (and C#/.NET) is not a viable option for AAA titles at this point is the established game engines and their toolchains are written in C++. Game development is all about getting a title on the market in the shortest amount of time, and budgets don't allow for piddling in things like a new language/engine when several are already available, work well, and have an extensive set of editors and tools backing them.
Moving to Java (or C#) would also require a new performance-driven JVM (or CLI) across the big-3 (PC, X360, PS3) or big-5 (add Wii, iPhone). It's technically doable, but not financially viable.
Edit: Anyone with low-level knowledge of both virtual machines and the current state of game engines can tell you that a JVM or CLI could unquestionably be implemented with a new game engine to beat the performance of current C++ engines. The preventing factor is time and money, nothing more and nothing less.

High performance and the inertia of C and C++ traditionally being used for games.
Choosing based on performance isn't that big a priority unless you are making a 3D extravaganza.

Because:
Java is not compiled to native code, meaning that there is a performance hit the first time the code is run.
Java does not give you a predictable memory model (console games need this)
Java does not give you deterministic object finalization.
Java is not as close to the hardware as C is, an essential for a lot of professional 3D game programming.
Console programmers likely don't have a JVM that runs on the PS3, X-Box, etc.
Runtime performance penalties.
You will never be able to squeeze as much performance out of a Java app as you can with a C++ app.
There are probably more reasons, like the fact that they are using pre-existing code that was written in C or C++.
EDIT: As an aside, I don't think that many modern games are written in C. OOP lends itself to game development, and C++ is the de facto language of choice.
Also, I won't add it to my list, but as others have mentioned there is a lot of pre-existing code that works very well that is used in the game industry. It would not be practical to rewrite all/most of your tools just to switch to a new language especially when that switch could cause you a lot of headaches.

I would say, despite the other answers pointing to a lack in speed caused mainly by the JVM, that the real reason people don't code games in Java is the lack of support for environments such as DirectX and OpenGL (which actually remove the need for your code to be close to he hardware as it was suggested by some answers). They are the base frameworks that people generally use to code games, especially nowadays with 3D games being everywhere - and lack of support for them is the reason why Java is not considered as a language for game development.
To emphasize my point, I would suggest you take a look at Microsoft's XNA which is currently optimized for coding in C# via the .NET framework (which like Java is Just-In-Time-Compiled and doesn't run natively per se). The XNA framework interfaces with DirectX which talks to the hardware and so it is very fast.
EDIT
#Ed Swangren's comment made me realize yet another distinction between .NET vs Java when considered for game development. I think another strong point to .NET is that if you do need to be able to squeeze out that last bit of performance and do some pointer math or implement a sophisticated high-performance algorithm it's a lot easier thanks to the unsafe mode. Of course you can even go beyond that and write native libraries to be used by your C# code which is made pretty simple thanks to P/Invoke.

Leaving C(++) aside for the moment... I am inclined to say much of the reason is that Java lacks anything like XNA. What advantages does Java actually have over a language such as C++ when it comes to game development? You have to consider that several of it's typical advantages disappear for the specific area of game development, while C++ gains several.
XNA is what made C# a highly popular language for amateur game development, and contrary to common belief, a quite viable option for commercial development too. C#/.NET being a parallel to Java in so many ways (and arguably a better framework nowadays), when people now have the option for game development with a higher-level language, C# would seem like the much more appealing one, unless cross-platform support is essential (then again, we have Mono and OpenGL for .NET).
C (or rather, C++) has long been the language of game development due to their low-level nature (thus performance benefits) and the host of graphics frameworks (DirectX, OpenGL) and engines that primarily target them. It's usage is embedded in game development and been used virtually since the inception of the industry - and won't disappear any time soon, I suspect.

Java doesn't have as controllable performance
Its highly reversable so harder to protect
Many Games employ scripting languages like lua or python to get "higher" level programming
the API of most systems is C oriented.
Java can be used for back end server systems that games connect to
Flash games seems to of taken the niche Java games could have had.

Java can be optimized to be very fast, as is evident by an interview I had recently with a high-frequency trading company, where they do use Java, as well as C++.
Java has OpenGL bindings, as others have pointed out, so getting to the hardware isn't such a problem, esp since not all games need that, some commercial games have been written for Java3D.
You can use Scala or F# if you want some more performance for multi-threaded or numerically intensive operations, and just tie those in with the GUI.
But, as others have mentioned, the tools that are used tend to be written for C++, and some companies feel more comfortable doing some optimizations in assembly, but, given the fact that the new cpus are very complicated, with multicores, it is unlikely you will get any performance increase over the optimizations from the compilers, but, as long as companies feel these optimizations are still needed, they will stay with C++.
If some developers wanted to write commercial-grade tools for Java or .NET, there could be a market opportunity there, but it will be a great deal of work to make it as good as what is already out there.

I think C or C++ is a better language for building many types of games because it is closer to the hardware and likely to be the first language implemented on any new hardware. Not only that the libraries for accessing many of the advanced features of today's hardware are likely to be implemented in C.
Your typically general purpose higher level language has no easy way to access features of the hardware unless it uses some type of binding layer to call the libraries which are written in C.
For instance how do you write code to access a GPU, or write a custom Shader, or write code that run well on a Cell chip, or run on an Iphone, or on a Blackberry in a high level language. Even when these things are supported, they come out well after other people are able to write games in C that use these features in games.
One compromise you can make is to use a higher level language like Java for most things and C where its needed. You will limit the types of platforms you support though.
Java might also be good for client/server games where the server is written in Java.

It's very hard to write a program that runs in constant memory without garbage collection in Java.

If you want to read statements from game studios who are happy to use java for serious game development then search on twitter for #javaforgames
https://twitter.com/search?q=javaforgames
By studying the Java developers tweets conclude that Java is good for game development if you use it in combination with a high level game engine API such as libgdx and jmonkeyengine that both ease development effort and makes the game tuned to take advantage of the OpenGL/ES hardware acceleration provided by modern GPU hardware.
Java do allow cross-platform goals using said engines on mobile, console and desktop.
Some game developers prefer java for the design phase of the game to engineer in-house tooling.
Java game studios and developers who seek the best performance can archive it by tightly controlling OpenGL by using JOGL or LWJGL directly. Also performance and flexibility archive this by writing their own engine, if time and money allows it.

I wouldn't say that it is always true that C is better than Java for game programming.
For example, if you want to write a game client which can be hosted in a web page, Java could be better.
When writing games which produce amazing 3-D graphics (e.g., Halo on the X-box), usually there is barely enough computing speed to generate all the pixels for each frame. In this kind of game, C would be preferable to Java because it allows the programmer to write faster programs -- at a large expense in terms of difficulty in extracting that speed.

I think it's mostly because c lets developers squeeze every last little bit of performance out of hardware, whereas Java doesn't, it's not low level enough for things like high end 3d video renderers. Basically c lets you squeeze out a couple more frames per second in your next gen shooter.

Inertia mainly... Although it's a bit old now, you can look at Jake2 (which is a pure Java port of Quake 2 with jogl as the openGL lib).
It can perform up to 85% as fast as the C++ original, which means it's fine for most games; especially modern ones which are more social and game play based rather than the limited "hard core" games.
I'd also suggest that most of the answers you get here are coming from a gaming geek/"I want the coolest hardware and games". For [these] hard core 3D games and gamers, that final 15% is hugely important, as that's what separates the $150 graphics card from the $500 one they just bought.
As John Carmack is reported to have said (something along the lines of): "If I were to enter games programming now, I'd program for the iPhone". e.g. it's not nearly as much fun to make the fastest game with the best 3d engine as it is to make the best game.

The console game market is about 10X larger (financially) than the PC game market. For current generation consoles, all the major programming is in C or C++ with some little bits of intrinsics or assembler. If you want to be a professional Game Programmer and work at any major game company, then learn C and C++.
More to the point, all the commercial cross platform engines that are that starting points for many commercial games are in C or C++ right now as well.
You may be able to work on small games in java and flash or even casual Windows games in C#. You can even code C# for XNA games but if you want to make REAL (pressed on DVD) XBOX 360 games you need to learn C++.
Speaking as a game developer at WBGames Chicago. We would not hire a programmer who didn't have strong C++ skills. The same is true at every other game studio that I know of.

The short answer is because almost no gaming platforms support Java, or if they do there is a much better alternative.
On the game consoles, seasoned game developers are using C because that's what they've been doing for 20 years. There's no compelling reason for Java games to exist there.
On the desktop, there are a few Java games, but they can't compete with the market leaders such as World of Warcraft.
On the web, Applets are long dead, and if you're going to make a casual game it's going to be in Flash.
In the mobile space, JME has had it's time in the sun but it's on its way to obsolescence in the face of far superior platforms such as the iPhone.
The perfect world scenario for Java to be a heavy hitter in the gaming world would be for Sun/Oracle to deliver a gaming platform like the Wii or the iPhone - a must-have device that everybody owns. Then, there is a good reason for developers to invest time into experimenting with new technology. But given Sun and Oracle's apparent lack of interest in the consumer market, the chances of them making a gaming rig are slim to none.

It's not a technical issue but purely a "client optics" issue for this.
Good Java code can run just as fast as good C++ code. It can access OpenGL just as fast as native C++ via projects like LWJGL and JMonkeyEngine.
The real reason is that Sun never put any effort into highlighting Java for games and they've never made any deployment particularly easy for Java games. It's a LOT of work and effort of the developer / team to create a seamless / smooth installation (and launch?) experience for the player.
Customers just don't "trust" Java games and bail during the install process when they see the logo.

Although old, no one here seems to point out
All the games and apps on Android are programmed in Java
Because not only is Android written in Java, so are most all of its apps/games/etc...

I will answer in a very different way.
If Java can nevre write a device driver like C, how can you Imagine that it would be faster than the language that the driver is already written in ?