(un)Smooth movement

Java 2D
#1

I’m having a bit of a problem with the smoothness of my graphics… or the lack of it!

I’m using a dead simple Applet and Thread, and the graphics are drawn using active rendering. My main loop is pretty traditional:


run()
{
   gameLogic();
   render(backBuffer);
   swapBuffers();
   try{gthread.sleep(20);}
   catch (InterruptedException e){}
}

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…

I’ve tried the program on all sorts of hardware and Windoze versions.

Any suggestions?

#2

[quote]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.
[/quote]
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´t think of anything without seeing the code.

#3

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.

#4

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.

Cas :slight_smile:

#5

GC is probably the reason…

#6

[quote]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.
[/quote]
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…

#7

Thanks for the replies :slight_smile:

GC would make some sense I suppose. I’m not doing much real code at all in the main loop though, certainly no alloc/dealloc. Just simple move->draw->wait->repeat.

Does GC always run at a set rate irrelevant of what your program is actually doing? I’ve not looked very deep into the mechanics of this before.

Its not a massive stutter, just noticable. Maybe I’m too used to my Amiga’s lovely smooth scrolling? ;D

#8

Yes, I know what you mean…

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…

But this does not influence smoothness…

#9

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.

#10

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.

Cas :slight_smile:

#11

To be sure how great the GC impact is, I use the flag -Xloggc:/gc.log for example. Especially look out for ‘Full GC’ reports.

#12

Thanks, I reckon some of this has made a difference.

Cheers ;D