Pixel-Perfect Collision Detection. There's a lot of demand for this type of endeavor but there arn't any specific examples on how people can get it to work for themselves. In an effort to help others where I struggled, here's a rundown on how to get pixel-perfect detection with Java.

The guy who wrote it, TANSTAAFL, lays out the math and other concepts pretty clear so I won't get much into that. I'm just going to go over how to get your bitmask layer and how to use it like he recommends.

sprite = ImageIO.read(absoluteRef); }catch(Exceptione) {System.out.println("ERROR: File " + ref + " not found.");// Just exit out of the image isn't found. It's pretty essential to the program so don't bother trying to run without it.System.exit(0); }

2) When you read an image like this, it dumps all of it's information into a byte array. Each pixel's data is 4 elements long in the array. The first element holds the pixel's Red saturation, the second is Green, third is Blue, and the last is the Alpha. For collision detection, we only need to worry about the alpha value. So, we're going to strip it out of the image's data.

Now that you have an array of the image's alpha value, you can refer back to GameDev link above and apply your collision detection technique.

If you're doing rotational collision detection, things get a little more complicated, but the gist of things remains the same. To rotate a position in an array, you can do something like this (Note: The below is pseudocode. It won't really work- you're going to have to use this as a guideline for how you want your rotations to be done.):

When this is done, the byte array named rotationLayer will have the alpha data of the sprite when it's rotated. You can then use this array to check against another 'rotationLayer' and do the same collision detection technique as you use for non-rotated images. The catch here however, is figuring out how to translate these coordinates into your gaming world so you can find the point of collision outside of just having a position in the array.

Later, I'll be posting a webstartable application that loads an image and dumps it's data into an HTML file. You'll be able to rotate the image and whatnot so you guys can get a nice feel for how things are supposed to go. Expect that later this week. For now, I've got a busy weekend ahead of me outside the coding world.

I hope this helped some people. Feel free to PM me with questions or comments. I'll try to do my best and help.

Edit: Whoops, I doubleposted before I was finished writing. I deleted the old one.

The reaons for doing so is easy. Most of the time there isn't a collision. Therefore it makes perfect sense to use easy to calculate tests for sorting those out before doing any cpu intensive accurate checks.

A low level logic optimisation like that can already give you a *huge* performance improvement.

There is also a higer level of logic optimsation. Like game rules (no need to check your bullets agains yourself or agains other bullets) and things like sectors or quad trees. So before you do the first step (checking if they might intersect) you determine if they have a chance to intersect. For example entities in the upper left quadrant can't intersect with entities in the lower left quadrant.

Well, each game is different. If you have for exmaple some kind of static grid (oldschool breakout or a tilebased jump n run) you won't need anything tricky. Because you "know" were you are and which tiles/bricks are next to you. In a breakout game those tiles of interest are those which are below the four ball sprite corners (if the ball is smaller than the grid you have 1, 2 or 4 cells, which you have to check for collision).

The topic is pretty broad... so I'll stop here. Over at gamedev.net and gamasutra.com are a bunch of articles.

I also recommand the article of those "N" (a flash game) guys. It has a bunch of interactive parts, which can be used to try (and see) those different methods.

That's the breakout example. The white box shows the 4 grid cells, which I have to check and the red square highlights the one which contains the ball middle. That one is somewhat special, because it's used for "sorting" the voronoi regions by importance (edge collision first[flat], vertex collision later[corner]).

If you wondering what I mean... well if there are two bricks next to each other and the ball hits somewhere in the middle, I want the ball to bounce off straigt (as if it's a single big brick). Therefore I care about those straight bounce off voronoi regions (edges within the white rect touching the red rect) first and about the corners later (if no collision happened).

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