The game logic is non existent at the moment, so it basically just throws things at the screen.

The problem is that while it maintains a fairly constant speed, it'll jerk/judder/stick every second or so. It's perfectly smooth in-between these judders, which makes it seem like (to me) that something is interrupting my program periodically.

My other thought was that some frames may be taking vastly different times to draw than others, causing intermittent speedups/slowdowns. So, I tried using a Timer object to invoke the drawing of frames at a set rate, and it made absolutely no difference.

I also wrote a small method to calculate the amount of time taken to draw a frame, and subtracted that time away from a standard delay. I then made the thread sleep for this amount of time. This should make each cycle of the loop take roughly the same time.. right? But it still behaves *exactly* the same..

The problem is that while it maintains a fairly constant speed, it'll jerk/judder/stick every second or so. It's perfectly smooth in-between these judders, which makes it seem like (to me) that something is interrupting my program periodically.

My quess is that the GC kicks in and make these small jerks. Check all your code in the gameLogic() and render code for any use of the new keyword. If you find any use of that get ride of it. Never allcolate new objects in your render loops, or gamelogic, this will cause the GC to start the garbage collection at times and make the jerks.

Other than that I can&acute;t think of anything without seeing the code.

In our 3D app we have the jerks as well. But this is quite independant of wether we create garbage or not. We had some test code in there that created thousands of objects/second. Vector3f, Matrix4f, Transform3D and such. We could not notice any effect. The numbers only showed up significantly when profiling.

I feel the GC in fact is a VERY fast action that does not disturb a game that has 10ms between two frames. The times the GC needs are far smaller AFAIK.

Of course, don't allocate some megs of something each frame - then GC certainly will kill you.

The GC seems to use about 5ms or so (despite what it claims) every now and again, which is about 1/3rd to a quarter of a video frame. However what it doesn't time is the heap synchronization overhead which it does - the heap has to be locked while it occurs - and I think this is where the pause increases substantially.

There's also now and again a bit of Hotspot housekeeping going on.

BTW, I'm allocating some kinds objects in my game loop happily without any real trouble - a dropped frame every minute or so maybe - such as enemies and the like. But very few of them.

The GC seems to use about 5ms or so (despite what it claims) every now and again, which is about 1/3rd to a quarter of a video frame. However what it doesn't time is the heap synchronization overhead which it does - the heap has to be locked while it occurs - and I think this is where the pause increases substantially.

There's also now and again a bit of Hotspot housekeeping going on.

But GC runs only now and then, the stutter is by far more frequent - that is what I felt. Maybe it's only one source of many....

No, the GC acts on demand, at least AFAIK and judging from its output. While loading our prototype it is VERY active, but when the game runs it comes up only every 5 seconds. If I increase available memory (-Xms256mb -Xmx256mb), it does show up after a couple of minutes....

If you do a lot of loading or affine transforming or anything before the game starts, it is good to run system.gc() after it. This reduced the jerkiness for me, because depending on the object, the GC decides whether to dump the object or not and apparently it doesn't dump affine transforms or image dumpsters unless it is absolutely sure they won't be used again. This means that every time gc runs, it checks through all these and decides wheter to dump them or not.

If you don't need something, try to set it into condition where the GC understands that it won't be used and dumps it right away.

It's almost certainly a GC pause, and it will happen regularly as long as any allocation occurs at all, and there's almost certainly a little bit going on somewhere.

The last vestiges of GC stutter I removed with -Xincgc and -Xconcgc - XAP runs smooth as glass (until there's a few hundred particles whizzing about that is).

I don't get the stutter when using Jet either, which leads me to suspect it's the new space garbage collector cleaning away a few short lived objects. Jet allocates this kind of thing on the stack where it can and invokes no GC penalty at all as a result.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org