Does really game development on Java suck? Why are we still here?

General Discussions
#61

The memory footprint isn’t anywhere near as bad as you might think. The actual in-use heap memory footprint of my games - or let’s say Revenge of the Titans specifically - is actually not vastly different from the equivalent that it might have been in C++. What might be fooling people into perceiving Java as a memory hog are the following:

a) jar files mapped into process space (in reality, only a tiny portion of most of the jars is actually being used)
b) graphics and sound effects kept in system RAM are huge - easily half of the memory footprint
c) the heap hasn’t exactly been super-tuned for efficiency; depending on how much time you’ve got to spare with GC you can shrink the maximum heap size massively
d) “bad” programming: GC tends to promote a lazy approach to conserving memory. I discovered a while back that the Strings in my configuration data were being kept after startup completely unneccessarily and wasting 50mb of heap - I now null them after startup.
e) overlarge vertex buffers

I think Java’s memory usage isn’t really massively greater than C++ for a non-trivial game but in these days of cheap RAM, we don’t tend to spend so much time ensuring that things fit in a tiny footprint anyway.

Cas :slight_smile:

#62

Quite! Though it’s always amusing to be flamed for saying something you’ve never said* I have never claimed that JNA is faster than JNI - how could it be, it’s built on top of it. I assume that the changes mooted for JDK 9 will also use a mechanism like libffi, and therefore probably be slower too. To which I say … so what?

My point about JNA has always been my point for using Java itself. Performance isn’t everything! Ease of development, deployment, robustness, etc. all come into it too. JNA and Java itself are usually fast enough - otherwise we’d be having this conversation on assembly-gaming.org. :slight_smile:

  • hence my possibly ill-advised PS before :wink:
#63

I think Java is great for game server development. This is a sector with a huge amount of support.
For the client/singleplayer side Java could be great, but there is a lack of support. Afaik Android games are not that profitable compared to iOS. So many people will look for iOS to Android converters and not the other way arround… Java became too complex before lightweight use of such languages/systems was chic.

I often think about converting Java bytecode to AVM2 bytecode. I think it would be great to be able to use Java and its tools for programming Flash. It may even improve the performance of Flash.

#64

Actually there was a time where many people were working on GUI libraries built on top of OpenGL for game purposes… Some of them looked really neat too. I wonder if at least one of them survived and actually became something more than a post on a forum.

Couldn’t agree more.

#65

TWL lives on, and appears to be quite excellent and very Swing-like.

Cas :slight_smile:

#66

The code memory differences are quite large. For pure objects (and ignoring other overhead like memory management bookkeeping, decomp framework, etc, etc.)


// HotSpot 32-bit or 64-bit using 32-bit address space
hotSpotRegularObject {
   uint32_t  klassPointer;
   uint32_t  shape;
   uint32_t  locks;
   // instance data starts here
}

hotSpotArray {
   uint32_t  klassPointer;
   uint32_t  shape;
   uint32_t  locks;
   uint32_t  length;
   // array data start here
}

cppObject {
   uint32_t klassPointer;
   // instance data starts here.
}

Couple that with the fact that we’re currently missing structures, arrays of structures and concrete length arrays…all this nickel-and-diming everywhere adds up fast. (Note this is the source of my whining about per-object locks and identityHash)

#67

Quite large on a micro level but in the grand scheme of things object overhead is irrelevant next to the memory consumed by graphics. A triple A title can have half a gig of RAM just used by textures to render a single frame.

I do agree you can let it get out of hand quickly if you’re not doing flyweight pattern or mapped objects to simulate structs but that’s only for very particular kinds of data in very particular situations. Nearly all the rest of the time I’ve noticed that the memory is actually being used by one of the places I outlined above - that is, wasted unnecessarily, in graphics/sound, in unused heap, and mapped jar files. Android gives a very slightly more simple picture of what an app might use as it’s nowhere near as sophisticated in its use of mapped files and the resource constraints make it manage memory in a slightly more understandable way.

Cas :slight_smile:

#68

Also that’s not at all the only overhead in a C++ allocation, especially if you’re mallocing it; both Java and C++ require memory management structures for keeping track of allocations on the heap, and there’s a similar bunch of bookkeeping structures used in both. The main difference is C++ can be forced to use the stack instead whereas Java has only recently started using escape analysis to do it automatically when prudent.

But still… just mostly noise in a non-trivial application.

Cas :slight_smile:

#69

Yes it is important to remember here is that most of us don’t really care about any of this. Chances are if you’re hitting performance problems that need addressing the issues are going to be more design and algorithm related than Java’s weak points.

WRT: moving graphics…different hardware is doing the work so this has (or should have) little impact on the work that the CPU can do.
WRT: moving computations to the GPU. This is overrated. You still want to get maximum computation from your CPUs as well as GPUs in bleeding edge work. Everything you move off to a GPU consumes time that it could be doing something else…like rendering (just a for instance).

#70

Wow and that one is already for Java and Android (based on LibGDX) :o Could it be “the chosen one” ?

#71

Yes. TWL is amazingly fast and versatile. It’s perfect for all your GUI needs :slight_smile:

#72

This whole Java development page is rather interesting since I used to be a C++ programmer before converting to Java. Java does not suck as a language, the amount of tests and routines I tried on it allows it to be a very good platform for game development. It is very well documented, allows you to deliver games solidly cross-platform, and is easier to use than C++. But, despite this, Java just has a lot of stuff working against it.

  1. Most of the world PC’s use Windows.

This is really hurtful because Microsoft basically controls the gaming market for PC’s. C++ is the language of choice and if you are going to affect 70% of the users, who cares about the 30% who get left behind. This mental picture was painted into a lot of my professors and colleagues minds. Support is just better for gaming in Windows and C++.

  1. You must do it Java’s way…

This is major. You can’t avoid the JVM, you can’t avoid naming classes with filenames, you can’t avoid the GC. Yes, there are ways to improve the performance of Java, but in the end, you end up doing about the same amount of work to cut off time, as you would to build the program from scratch in C++. Indie gamers will flock to it because the concept is easier to grasp than C++. Indie gamers love easy to learn concepts. But, to get the true speed out of Java, you really have to put in the extra effort required for C++/C. I specifically found it rather difficult to argue which language was superior.

  1. Popups

The one complaint I got from users the most was “Why the pop-up?” People just want fast deployment. Indie gamers usually never take the route of packaging the JVM, making things a lot worse since every time, you’ll eat the pop-up. In reality, the “Java is slow” mantra has spread more than just comparing it to C++.

The users are basing it on how long it takes for when you click the application, to when you actually get to run it.

So, if the deployment time is stopped by a loading screen, a certificate pop-up, and a request to download the latest JVM. It doesn’t feel as intuitive as just click .exe program and run. Java might be a lot faster in processing speed, but deployment still seems to be tearing Java’s sails. Users immediately think pop-up = bad! (thanks a lot spam) so it works against Java.

I continue to use Java because it has a user community that actually cares about the language. Also, you are never short of documentation on how to get something operating. Its connection to Android is really a deal maker, and I think Java should push itself more into gaming platforms (like Playstation & Wii) and phones (iOS) if possible. I hate the fact that people think of Java as niche software for making quick simple applications. Java deserves more than that. It is a very capable language now, and I think if we don’t give up on it, it has great potential to be the next C++.

#73

A few observations from the front line:

  1. About 10%-11% of gamers on the other hand use Macs, and honestly, the users of Windows or Macs don’t care a hoot what language you wrote a game in so long as it works with a minimum of fuss (see 3 below). Some vanishingly small % of ordinary people use Linux, though through random chance it turns out about 10% of our customers use Linux for some inexplicable reason.

  2. Java’s way is absolutely fine 99.99% of the time. It is “normal” for C++ programmers to be upset by this and try to fight the GC, established naming conventions, general design patterns, etc. Eventually the whole concept is grokked and you end up spotting the real issues, which is where you start finding all these discussions here on JGO about mapped objects. Sometimes there’s concern over performance - it being about half the speed of C++ in general - but as nobody here on JGO is actually pushing current hardware anywhere near its limits this rarely concerns us much and usually it turns out that it’s actually algorithmic design or GPU limited code that is the problem, just as in C++.

  3. Nobody who seriously develops Java games (unfortunately the number of studios who actually do can be enumerated on one hand or thereabouts) actually uses a system JVM on Windows, or actually uses applets. Except for Mojang, and they’ve had all kinds of trouble from it, but that’s because Markus started from scratch with no real knowledge or care of the issues around it all and had no idea Minecraft was going to be quite so successful.

Android’s great … for mobile Java development. I don’t think its existence is going to have any useful effect on the perception of Java desktop applications.

Cas :slight_smile:

#74

If you are making a premium title game, yeah. Otherwise I would be careful.
Macs and Linux have a nice base and are interesting markets.

Your last line really is the most crucial point. Far to many people do not have the basis to make such a comparison.

Also the bias and habits get in the way.

If your game has a certain size, you could also simply package the jre with the game.

Note that in C++ you could have similar problems. Do you have the runtimes needed? The right gfx drivers? DirectX?
People have no problems doing all this for C++ game, but if they have to do it for Java it is totally unusable all of a sudden?

While I no longer really do any game dev, I still use Java for basically everything simply because it can work everywhere and do nearly anything I need.

#75

Very true, but with one difference: most if not all of that stuff is dealt with through windows updates or even platforms such as Steam - you hardly ever have to think about it anymore as the end-user. Java on the other hand is managed separately and in a far more intrusive way. On top of that, Windows update hardly ever fails (Microsoft is not flawless of course) - the people at Oracle aren’t too good at creating reliable installers that work on all machines and under user configurations reliably, the Oracle forums tend to see a major increase in people having botched installations which are near impossible to repair each time a new update is released…

#76

Reiterate: no-one sensible uses a system JVM on Windows. Mac OS always works. Nobody cares about Linux.

Cas :slight_smile:

#77

The appeal of Java is that it is well designed “little” language. And the “little” part isn’t meant to be derogatory. The syntax, on the whole, is nice and clean. It’s a very good first language as it doesn’t have a large learning curve to get up and going. The set of tools & libraries that are freely available are excellent (OK, on the library side there are some big gaps…numeric stuff comes to mind…but most of us don’t really care about that). On the performance side, it’s quite excellent when compared to dynamically typed languages and is more than sufficient for vast majority of gaming needs as long as your not attempting to compete at the top-end of the spectrum. And if you are, then the fact that it’s unlikely that you have tens of millions in budget is probably a much bigger hurdle than any performance issues. (Of course all generalizations will have exceptions)

So, to my mind questions like: “Why isn’t Java more successful for games?” or “Why don’t big studios use it?” are not very interesting. Question like how to improve user experience (such as deployment) and how to handle current limitations are much more interesting.

Coming back the the performance (and usability) side, what bothers me is that most of the big issues (again for me) are fixable with current technology.

#78

Er, if it was 10% of my customer base, I’d be caring about it! :wink: Do I think that 10% is reflective of the overall Linux user base, no, but nor do I think it’s vanishingly small either. Interesting reading things like http://broadcast.oreilly.com/2010/09/debunking-the-1-myth.html, or the stats on http://www.humblebundle.com/ which show Linux share about equal with Mac and less cheapskate too! Your 10% may reflect a more tech-savvy audience for indie games, who knows, but it just might show it’s worth caring about.

How can you criticise this??? One of Java’s best features IMO, and one reiterated every time I try and grok some code in another language and have to spend time wondering where the f**k someone has hidden something.

#79

Object Oriented programming isn’t exactly easy to pick up ya know :slight_smile: Its easy to pick up when you already have programming experience; when you’re new to the scene I’d hesitate to say that a language like Java can actually be a hurdle. Better start out with something flat and sequential. Like our beloved Pascal, but I’d settle for something like Ruby as well :slight_smile:

Agreed, but there is still a major problem that stumps people - there is no “java executable” to start. The tools are great, but they are fragmented.

Us experienced folk don’t, no. But again: major fragmentation and even conflicts; in my opinion the “api/implementation” idea that Sun basically forced on the language created far too much confusion. You keep the platform open, but also create lots of confusions because there are multiple implementations floating around for each API. In some cases Sun/Oracle even neglects to provide or update the reference implementation :confused:

Agreed. It doesn’t help to keep tripping over what doesn’t work, better to focus on fixin’ it. Java has always been community driven to begin with, waiting for Oracle to step up simply isn’t productive.

What bothers me the most is that the knowledge is in your head and not somewhere where I may benefit from it :wink:

#80

The only reason we have that many Linux customers is because of the Humble Indie Bundle. Linux also accounted for 90% of our support costs as well - problems generally being more common, and more difficult to diagnose and fix. Almost no support whatsoever for Mac OS - it’s a model citizen with Java and OpenGL, at least how I use it anyway. Windows somewhere in the middle.

If you’re not in a Humble Indie Bundle you are basically wasting your time supporting Linux. That hasn’t stopped us supporting Linux for the last 10 years of course, but you should know it’s basically a time sink you do in your spare time for the love of it.

And:

I still think BASIC is the coolest language ever.

Cas :slight_smile: