I've made a little avoid'em'up-game for this years Java4k. It runs smooth on some computers, but when I test it on one some "older" computers the animation is a bit jerky and I run into some irritating stuttering .

I have these problems on an older Linux laptop (in Firefox), and an older Windows 7 box (in Internet Explorer). However, when I run Chrome on these computers the game runs fine .

I've made some Java2D games before, but I have not experience rendering issues then. For example, my entry for last years Java4K runs just fine.

I've done everything I can think of (even desperate things): testing with different timing approaches, busy timing looping, non-busy timing looping, reducing painting operations, removing object allocations, reducing floating number operations, removing code, and so on... but nothing seems to solve this. Obviously I'm optimizing the wrong things, and I have a hard time to find the real issue.

This is starting to drive me crazy. What am I doing wrong? Do you have any suggestions?

I'm attaching the source code for the project. It's not very many lines of code, but since it's a Java4K-project the readability may not be the best. Just ask me if you need any specific details or info.

If someone wants to help me I would be very happy and grateful. Help me JavaGaming, you are my only hope!

/* * Legend of the package delivering hero * Copyright (C) 2012 Jens Stääf * * Legend of the package delivering hero is free software; you can redistribute it and/or modify * it under the terms of the GNU Lesser General Public License as published * by the Free Software Foundation; either version 3 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, but * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License * for more details. * * You should have received a copy of the GNU Lesser General Public License * along with this program. If not, see <http://www.gnu.org/licenses/>. * */

I haven't had any real problems with frame rate. (You can test to see how it runs by trying it.) Older computers always have a much slower frame rate for Applets by my experiences, but they usually run okay when dealing with JFrames.

Can you give an example of an "older" system that presents the issues? I have started 10 parallel instances and there was no slower frame rates.... but that said, if this is for java 4k then you should really only care about making sure that it will work well with JRE7 and hardware that most people would have... i guess one would look at Steam's statistics for that info.

I haven't had any real problems with frame rate. (You can test to see how it runs by trying it.) Older computers always have a much slower frame rate for Applets by my experiences, but they usually run okay when dealing with JFrames.

I'm pretty sure that the issue have nothing to do with the timing code. I've tried with different kind of timing strategies, but the problem still remains.

Can you give an example of an "older" system that presents the issues? I have started 10 parallel instances and there was no slower frame rates.... but that said, if this is for java 4k then you should really only care about making sure that it will work well with JRE7 and hardware that most people would have... i guess one would look at Steam's statistics for that info.

Both computer have Intel Core2 Duo processors and 2GB ram. Both are using cheap build in graphic cards. They are not really old, but it' no state-of-the-art machine. Still, I feel they should be good enough to run a simple Java applet game.

One the Windows laptop the game is still playable, but the framerate is bad and the animation is not very smooth. The experience on the Linux box is both better and worse - the framerate is much smoother, but every now and then there are short freeze-moments. I usually associate such freezing-moments with the garbage collector, but I can't see any reason for the GC to kick in (since I'm not allocating very many object).

I had a quick skim and there's no obvious need for regular garbage collection - Event objects will be generated by AWT, but they're small. You could try running with -verbose:gc just to check that.

The other obvious step for some non-intrusive profiling is to print remaining to System.out. Are some frames taking longer than the allocated time, or is the problem in the waiting?

Thanks for the tips about running with -verbose:gc! The gc kicks in from time to time, but there seems to be no connection with the freezing-moments.

I've tried to print the "remaining"-value, on both computer. On my main computer (where it all work fine), there is a very small variation between the time frames. On the "slower" computers the variation is bigger, but I can't see a straight correlation between the variation and the stuttering.

To diagnose the problem I've tried to remove almost all the code, and just keeping the scrolling stars, but the problem still remains on the two computer:

The Linux box is running OpenJDK, but the game is running fine with OpenJDK on my main computer. The windows laptop is running the official Java 6 from Oracle, and the official browser plugin for IE. In Chrome everything works fine for some reason.

I've tried to print the "remaining"-value, on both computer. On my main computer (where it all work fine), there is a very small variation between the time frames. On the "slower" computers the variation is bigger, but I can't see a straight correlation between the variation and the stuttering.

If it doesn't go negative at all then that rules out one important candidate problem.

I'm out of relatively sensible ideas. The more outlandish ones would include using renice on the Linux box to see whether it's a scheduling issue; disconnecting from the network to eliminate some interrupts; disabling antivirus on the Windows box; and using fullscreen exclusive mode to limit the other traffic to the graphics card. But I'm not particularly bullish about any of those.

I've tried to print the "remaining"-value, on both computer. On my main computer (where it all work fine), there is a very small variation between the time frames. On the "slower" computers the variation is bigger, but I can't see a straight correlation between the variation and the stuttering.

If it doesn't go negative at all then that rules out one important candidate problem.

I'm out of relatively sensible ideas. The more outlandish ones would include using renice on the Linux box to see whether it's a scheduling issue; disconnecting from the network to eliminate some interrupts; disabling antivirus on the Windows box; and using fullscreen exclusive mode to limit the other traffic to the graphics card. But I'm not particularly bullish about any of those.

I've seen the "remaining" value go negative a few times, but I can see no connection between the negative values and the freezing.

Since the problem seems to occur even if I run the program with just the bare minimums, and since it works fine on most computers, I guess that I have to ignore this problem. I've spent to much time already on this issue. I'll upload the game to Java4k wait for feedback - if everyone complains about performance issues I have to take another look.

Thanks for your suggestions, and thanks for taking time to look at the code!

Probably a silly suggestion, especially for a java 4k game, but have you tried promoting the priority of java process running your game? Perhap your OS is being a little to sparing to the process?

There must be something weird going on with the Linux box. I see serious stuttering even if I remove all application logic, all timing code and almost all rendering code. The framerate is not perfect on the Windows laptop (in IE; it runs fine in Chrome), but the game is still playable. I'll upload the game to Java4k wait for feedback - if everyone complains about performance issues I have to take another look.

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