Java game programming

Hi there,

I just wrote a small blog post about my experience in working with Java for game programming. It is mostly things I stumbled upon while working on Caromble! for the last few years.
While we’re not using JMonkeyEngine but its siter Ardor3D, it could still be a nice read for some. :amused:

Check it out: http://www.goo.gl/GD7nm

Grts!

Peter

4 Likes

Thanks. Only thing I’d have to moan is that C++ code compiled for a specific platform can never be as optimized as Java code compiled by a JIT for the platform it runs on :wink: Don’t take the defensive stance, take the offensive one ^^

2 Likes

With the specific exception of consoles - where they can optimise for the precise hardware.

Very nice writeup, Thanks for pitching in for the Java game dev community :slight_smile:

Hm… that post still harps that tune of “lots of garbage objects are a problem”.
Not a problem on the desktop and newer Androids AFAIK. It’s curious that Peter doesn’t mention that - am I overlooking something, or is it him?

<cite>@toolforger said:</cite> Hm... that post still harps that tune of "lots of garbage objects are a problem". Not a problem on the desktop and newer Androids AFAIK. It's curious that Peter doesn't mention that - am I overlooking something, or is it him?

Well, for a very long time it wasn’t a problem for us either. The garbage collector can handle pretty large amounts of garbage. It was only when our game grew larger and we had more and more objects spawning even more garbage that we started to get stuttering from garbage collections.
Funny enough, it happened more on machines with higher framerates (more fps is more garbage per second). So basically there seems to be a point the jvm minor collections are no longer able to keep up with the amount of garbage you leave behind and your un out of heap space. This in case will trigger a major garbage collection that will actually pause your game for x amount of time (depending on processor speed and heap size). Even if the pause is less than 300ms it is really annoying for an arcade game like ours.

Implementing pooling at some very specific places (basically the most called methods in the root classes where all gameobjects extend from) made sure gameplay remained smooth for us.

But I totally agree with you, only worry about the garbage collector when it actually causes problems.

Grts!

Peter

Ah yes, there are two things that could cause stutter as applications get large.

One is that it’s still stopping the world for tracing live objects. So a huge amount of live objects might run you into this kind of trouble.
The other is that long-lived garbage can accumulate, and I dimly remember having read that collecting the older generations (Eden or whatever the JVM-du-jour calls it) is still a stop-the-world collection. I might be wrong with that.

If would be interesting to know what’s the real source of stutter is.
Also, what constellations caused it for you - that would allow others to compare and maybe find out more about the reasons.

Hey guys!

What software developing method do you think I should use for a 3D game?

Ps.: Sorry if it’s an off topic

<cite>@toolforger said:</cite> Ah yes, there are two things that could cause stutter as applications get large.

One is that it’s still stopping the world for tracing live objects. So a huge amount of live objects might run you into this kind of trouble.
The other is that long-lived garbage can accumulate, and I dimly remember having read that collecting the older generations (Eden or whatever the JVM-du-jour calls it) is still a stop-the-world collection. I might be wrong with that.

If would be interesting to know what’s the real source of stutter is.
Also, what constellations caused it for you - that would allow others to compare and maybe find out more about the reasons.

The first one is solveable by using the concurrent garbage find stuff in the jvm.
The second can be solved by reducing the ratio quite much, so that only actually long used stuff ends in the long term part.

Is there a way to activate these solutions on Android?
I wasn’t aware that there is, but them I’m no Android expert.

On andorid im not so sure, but as far as i kow they made some improvements in the latest versions.

Well, I don’t know much about Android either, but now I’m confused.

On the first issue (tracing a large set of live objects), how do I activate background tracing?
On the second issue (stop-the-world GC on permgen data), I don’t think it can be prevented at all. Eventually, the permgen will soak up enough data; at best, you can make that event rare (say, once per three hours).

Well two worlds, android uses a own special jvm wich works somewhat differently, since i have not done that uch with it i leave this free for others to fill.

On the desktop however (using a hotspot jvm (eg openjdk or oracle/sun):

I suggest to read this here http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html as there are a few dozen combinations of the configuration, and what you wnat ot archive.

(Usually in a game i suspect no pauses longer than like 10ms and very rarly, however since usually multi cores are used and 1-3 of them are idle it can be more processing intensive on those)

Be aware that the concurrent one does use up to one core on my i5, however is able to reduce pauses to none perciveable. (I suggest an option in any released game to allow it to run on slower machines without excessive cpu power or less cores)

Additionally in almost any game you have some kind of loading somewhere (level, cutscene, scenechange or other uncritical parts where a short lag might be accepted) use those and call a System.gc in them, if they happen more often than every 3 hours you are closer to the target again, regardless of machine and processing power.

Also if you use 1.7 this one comes in additionally
http://www.oracle.com/technetwork/java/javase/tech/g1-intro-jsp-135488.html
For g1 you can set a soft limit on how long the pauses are allowed to be. eg the 10ms.
While it does not collect everything fast, it is often enough to clean up enough till the next level and an explicit call.

It also might be noted that having a very flat object graph like it is for example common in entity systems can speed up things a little, as the work required ot find out if something is garbage is fairly lower. Of course this is not a good reason to start rewrite a already fine game :wink: