Quote:Original post by SnotBob
I had no idea that there was a slow motion feature. You might wish to place that note closer to the center of the screen and in a bigger font.

BTW, The jerk appears even when I click on an empty spot, when the explosion circles don't appear. What are you doing in response to the mouse release event? I guess you're iterating over all of the circles and testing for hits. How many circles are there? Are you doing something else?

For collision detection, it is not iterating over all the circles. This would be slower, I think, and also there would be no easy way to tell which circle is on top in the case when you would hit multiple circles. Everytime you fire, a "collision image" is drawn by painting just the circles (none of the explosions or ripple effets), each with a unique color based on their internal id number. Then using the mouse coordinates, I get the color of where you are aiming, and if that color is not black, you have hit a circle (whose color is also its internal id). Its very fast and perfectly accurate collision detection which will take less than the time it takes to draw the screen once to perform.

Only a couple other things occur when you shoot:

1) the cursor changes color
2) ripple effect is created (very cheap i doubt this is the problem)
3) PixelGrabber object is created (used in the collision detection process to grab the pixel color of a given pixel from the collision image).
4) if you hit, a explosion is created at that point; again very cheap process.

I am not creating a new image everytime you shoot; the old one is cleared and reused.

I have modified the starting screen to be more helpful. Note that for your browser to reload the JAR, you have to close it and restart it. Otherwise it will continue to use the old JAR.

well obviously unless you are using some sort of grid to sort the circles, you will have to iterate through them all when detecting hits. At any one time there are only 50-100 objects on the screen (usually like 60); I didn't think that would be too bad to iterate through.

Maybe you are right though. I was thinking this sort of "picking" method would be faster than doing the calculations for every circle to determine if the given point is within its bounds. Since the actual painting to the image is fast, and since the image is never actual displayed on the screen, I thought it seemed reasonable. Maybe creating the PixelGrabber object for the image is slower than I thought?

I remember when I first added in collision detection and not seeing any noticable delay. I can smash down on the mouse as fast as I possibly can and not notice anything.

How fast is your computer? I'm on a core2duo, maybe that has something to do with it.

The game is finished now. I made modifications to the hit detection so that it uses simple bounds checking, instead of the image/color thing I was doing before. SnotBob if you are around I would be curious to see if you can see any performance difference. I also made some other changes to improve drawing, and smooth the circle animations more. Most of the change is just the addition of global highscores, which it turns out probably took just as long to write as the rest of the game.

The only issue I know about with the game is a problem with the Opera browser and retrieving the highscores. To retrieve the highscores, the applet just grabs a text file off the internet, and for some reason in the Opera browser it will keep grabbing an older version (presumably cached somehow?). It doesn't happen with IE or FF. If anybody has any ideas how to fix that, please let me know.

linky!