Applet, Mouse IO, and Performance

Newbie & Debugging Questions
#1

Hi, thanks for reading,

I am doing some basic ‘research’ and i’ve written an Applet that animates a ball and moves a paddle using MouseMotionListener. The Applet implements Runnable, i got this idea from a tutorial somewhere, i say this because i’m not entirely sure how that’s working. I know it fixed the problem i had where [i guess] the Applet Thread hogged the CPU and the IO was never processed.

My problem is that there are blips in performance. I can see the blips visually as well in the output on the console. I say output the currentTime - endOfLastIterationOfLoop, that’s probably confusing so let me give it to you in pseudo code:

time1 = System.currentTimeMillis (); // for first iteration.
while (true) {

    ball.animate ();

      
	time2 = System.currentTimeMillis();
  	System.out.println (time2-time1);
  	time1 = System.currentTimeMillis();
	      
 	repaint();

}

so the output is something like
…
…
…
0
0
0
0
0
0
15
0
…
…
…

I tried using Thread.sleep(), inserting a 10ms delay, which results in:

16
0
31
16
15
16

Mostly it’s 16s and 15s but that occasional 31 bothers me. I suppose this is Garbage Collection?
Actually those zeros bother me too. Is this a matter of System.out.println (timeDiff) rounding the long value to zero? Or is this value actually zero? If the Thread is supposed to sleep why doesn’t it? I understand it goes long because the timer on XP is ~15ms. And the 31ms delay seems to be ~double the 15 or 16.

I suppose i should do a test myself, but is this behaviour similar in an Application / WebStart ?
Would something like http://javolution.org/help?

And what about how this problem scales? If/When i have a large number of objects to animate and more IO to accept and more game logic to compute, what happens then? To me it seems it would get worse.

EDIT: thanks again!

#2

Looks like an issue with the accuracy of currentTimeMillis(), which unfortunately isn’t 1 millisecond. You might want to try use GAGE timer or some other alternative to check.

Kev

#3

am i asking for too much accuracy or is it reasonable to expect a higher frame rate?
Do the frameworks / engines for java games all fix this problem?
Thanks for pointing me to GAGE Timer, but ideally i’d like to have a pure Java solution, if possible.
I notice Jake2 (the Quake2 port in java) says it’s pure Java how could they manage to pull it off?
Is there a way of checking User IO on your own terms instead of AWT based? (Although Kill Game Programming in Java recommends AWT - as far as i’ve read)
If i’m asking riduculous questions just let me know… or just don’t respond i guess…

actually i’m wondering if Jake2 takes the hit of a 15ms timer. It has a max 66 FPS, which is good, but those little blips in performance are annoying, so could that be fixed with better garbage collection handling? I guess i may try that route though my programd doesn’t seem to be doing enough to require serious GC.
I’ll read more KGPiJ

EDIT: am i taking the wrong angle on this? i suppose using native binaries becomes necessary for OGL so maybe i should just learn native binary linking and get on with it?
I noticed something in a Java3D tutorial or something or other that mentioned a ‘wakeuponawtevent’ method… thought that might help…

#4

[quote]It has a max 66 FPS, which is good, but those little blips in performance are annoying, so could that be fixed with better garbage collection handling?
[/quote]
Without knowing what’s causing those performance blips, it’s impossible to tell if GC is to blame or not. Most likely however, GC isn’t the cause unless you’re doing huge numbers of allocations each frame but I guess for just an animated ball and paddle that’s not the case.
Try the -verbose:gc switch

I’m thinking it’s probably caused by coarse timing. You could try to measure timing across multiple frames (10 frames for example) instead of each frame and mediate the results.

I’m not sure how Jake2 is doing it’s timing, but I think it’s open source, right?

Another thing you might want to try is to use the (mediated) timing results to cap the frame rate to 60fps or something (using Thread.sleep()), it might lead to more consistent frame rates.

In any case, profile to be sure what’s going on!

#5

I think you misunderstood the accuracy statement. It did not neccessarily reference to your performance problems, but to the fact, that you measurement is flawed, since the System.currentTimeMillies() just don’t return milliseconds, but “jumps” around in chunks of ~15+ milliseconds depending on your system.

To measure times, the easiest would be to make your game require a JDK > 1.5 and use System.nanoTime()

Regarding your performance problem, it is hard to tell without seeing your actual rendering code. There are a lot of possibilities to cause this “blips”:

- You are using the inaccurate timer to calculate you ball-movement

conclusion: you don’t have a peformance problem at all, just your math is influenced by the
currentTimeMillies shortcumming

solution: use System.nanoTime() or meassure the time over a larger duration (e.g. 10frames)
and divide the result as needed

- You are updating your coordinates only in the mouse listener callback

conclusion: the mouse listener is called an an irregular basis, so you migt get to many
or to few events for a smooth animation

solution: try to smooth the mouse-movement by calculating averages for mouse movement
direction and speed based on the mouse listener callbacks and animate you movements in a
constant render loop based on this values

- You are repainting the panel inside the mouse listener callbacks

conclusion: depending on your rendering speed, this might block enqueue mouse events,
so you get jumpy time frames between the mouse listener calls.

solution: do the rendering in a dedicated rendering loop by painting on a BufferedImage
and just blit the finished “scene” to the panel in an SwingUtilities.invokeLater() call. The last step
could possibly be circumvented by (in/re)-validate/repaint your panel, but I am not so familiar with
realtime animations in Swing/AWT.

Maybe there are other possible problems, too