Game starts stuttering *randomly*

Newbie & Debugging Questions
#1

I used to think it was random, but not anymore. Basically I have a game that is a top-down, 2d and tile-based. There is smooth animation from tile to tile. At least for the first minute or so. I put the game down for a while because I could not figure out why, after a minute or so, it would start stuttering. Then I noticed while profiling it that once the heap space starts filling up and the garbage collector switches on, then that is when the game slows down.

In the heap space panel, the slowdown happens right after that first steep drop in used heap space.

I’ve had a few basic computer science classes, but 90% of what I know is self taught, so this is getting to be outside my ability to think through. I just wanted to know if someone here could help me out, give me a kick in the pants for overlooking something stupid maybe? Also I’m not sure what else to provide, but will post whatever is asked for. Thanks.

#2

It seems you are creating too many objects. The GC is known to cause slow downs for massive memory recall like this. Try reusing and minimizing the number of objects you create.
Do you use Java2D or OpenGL?

#3

I am using OpenGL. Too many objects, hmmm? I’ll see what I can do about that.

#4

You can try with larger heap size; This is what I do on my aplet

#5

Adding a larger heap size had some interesting results. It didn’t quite stutter like it did before, I’m guessing because it didn’t go through some massive garbage collection. However pretty quickly I noticed that there were small little pauses. It’s hard to say, but I think they happened every second. Unfortunately my map was randomly generated and did not have the room for me to walk trough more than two hiccups at a time. So an improvement? I suppose.

ra4king is probably right about my objects. When I started the project I was obsessed with making every little distinct thing it’s own class. Therefor I have a MapManager object, which holds (for testing purposes) just one Map object. That Map object uses a 2d 50x50 array of Tile objects. I never thought about it at the time but yeah that’s 2,500 objects for just one map! For shame me, for shame.

I’m not quite sure how to take all of the information stored in the Tile object and integrate it with the Map object. Assuming I can store it all in array form inside it’s Map parent, would that help things? Is a giant, information stuffed single object better than a simple object that stores all the info in other objects?

#6

Right now it looks like you have a very small heap size since you’re doing a garbage collection at 20M so I wouldn’t say you’re creating too many objects, its more that you’re creating too many objects for the size of your heap. 2500 objects isn’t that much so I wouldn’t worry about it. You’re running your app in under 20M of memory, which is insignificant compared to the GBs that triple-A games require and computers can handle those fine.

If you’re running it as an application, instead of using the applet syntax pitbuller gave, you can use “java -Xmx350m …” (so very similar).

Also there are many types of garbage collectors and parameters for each collector that you can use with Java. The default one does a pretty good job at being low pause until it has to do a full collection (which is probably the big drop that you see in the profiler). When the default collector does a full collection it blocks the program until it completes. There is a parallel garbage collector called the Concurrent Mark and Sweep collector that I like to use.

It is less efficient but runs in parallel the whole time so the visible stuttering is much reduced. You can turn it on with “java -XX:+UseConcMarkSweepGC …” and see if that helps.

#7

Well lhkbob, I tried it out, and noticed a couple of differences. However, after a moderately sized GC, the game went right on stuttering.

#8

I had a memory leak on a program. The program would start out at around 20MB, but it didn’t start stuttering until the heap space had grown into the range of 500MB to a gig, depending upon what else was running at the same time. So, I would look elsewhere.

There is a slight bump in the number of threads at the point you said there was stuttering. It is possible that these threads are blocking each other? Do all your threads occur on the swing EDT (in which case that thread might be overworked)? I think a look at thread activity might be a useful step in figuring this out.

Also, I’m curious what you are using for a game loop, and if there are possible tasks there that are causing single iterations of the loop to take longer than the period it is designed to run within.

EDIT: the activity on those threads that pop up and disappear might give a clue as to where blocking might be occuring.

EDIT #2: can also try making a smaller board and seeing if the error still occurs.

#9

philfrei I’m using FPSAnimator to control the game loop. I’d like to keep experimenting, but I’ve to get ready for work. I might be on after work to see what others have to say, but will not be coding (programming + vodka = bad).

I do have to say that Threads were never touched upon in the classes I took. What little I know about them is entirely self-taught, and probably encompasses about 4% of what there is to learn.

Thanks for the advice so far, and later folks!

#10

You need to profile the memory usage of your game. Whatever objects your creating loads of, that is the cause of your slowdown.

Common culprits include LinkedList, HashMap, TreeMap, or any in-game objects your creating 10,000s of like background stars or bullets.

#11

Also keep an eye out for objects that use a lot of memory - big arrays, buffers, etc. being allocated on every frame - they can definiely be worth reusing.

A slight extension to lhkbob’s suggestion - when doing low latency audio work where the margins are much tighter and less forgiving, I use

java -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing

works well for minimising GC pauses. NB. The last option may not be needed as I think it’s now the default on Java 6 when specifying the first two.

#12

Just -Xincgc works fine for me.

Cas :slight_smile:

#13

Thanks these are good suggestions. I do remember Hashmaps being used a lot, when I profiled the game. I’ll have to track those down. I have buffers that hold the vertex and texture information, assuming those are included in what you meant. I don’t allocate them every frame. Just the few I start with that are reused (info deleted by standardized delete methods and simply repopulated). That stuff doesn’t happen every frame, either.

Anyway, I’m still keeping an eye on this thread tonight, to spot any new ideas. Thanks again.

#14

There are alternatives to hashmaps out there, I have my own CachingHashMap which I use instead, but there are faster options around. So it could be as simple as just swapping out the HashMap for an alternative one, and that’s it!

#15

Well I’ve done some digging and it seems that a lot of the generated objects are a bit outside my control, byproducts of the greater complexity involved in using JOGL and font rendering and so on.

Some of it may also be caused by un-optimized JOGL. I’d say 20% of all the time I spent learning Java was dedicated to wrapping my head around VBOs, and shoehorning them into my engine. Basically, I believe I’ve got it right, just not optimized.

The good news is that for some reason my game has settled down. I tossed -Xincgc in there, and I’m not sure if it helped, but seems like it might have. There are just the occasional pauses when a larger collection occurs, but I ran the game for over 4 minutes with just a scant few hiccups. As this game is just a personal project to share with friends, I can live with those. Time to get on with it!

Thanks for the help, folks!