Title pretty much covers it. Is it worthwhile to do pixel-perfect collision detections, or is the hit in performance too great? Obviously you wouldn't want to do this without having some basic bounding boxes too, but I for one am tired of collisions that don't visibly occur. And plus, I have some special things I want to do with collision detection that would be a bit trickier to implement without pixel-perfects. But here I'm asking about the general case, where you just have two sprites, each with a mask, and you want to know if they overlap at all.

I think they're worth it to the game play experience. One alternative you could try that's commonly used, however, is to shrink the bounding boxes around the sprites a little bit, so you'll almost always get some visual overlap on the sprites before the collision occurs.

It's not that big of a performance hit either. Whenever two sprites collide, add them as a pair to some sort of list or array or something, then finish your collision detection. Then once you've figured out who collides by BBox, you go through the list and determine what area of the two sprites' BBox's are overlapped; then you only test the pixels in that given area. With a little bit of creative flow control statements and a little looping, you've really not incurred that much of a performance hit, and you've made your collisions much more realistic.

However, if you're not into all that, like I said you could do the shrunken bounding box trick

(edit) sorry for the double post.

[Edited by - andrewk3652 on December 4, 2004 3:57:00 AM]

Just a little note: in Manic Shooters, the size of the collision box of the player's ship is one pixel high, one pixel wide. Any bigger than this and the game becomes unplayable. An example of a case where completely unrealistic collision areas actually add to the gameplay. For everyone who might disagree, I strongly suggest trying out a manic shooter if you didn't already ;-)

Other than that, you could always use a big bounding box to detect possible collisions (not collision themselves) and then have a few more checks on the sprites to determine whether there was a hit or not, using smaller bounding boxes. Usually, pixel-perfect accuracy is overkill, as four- or eight-pixel wide boxes perform well enough.

Why don't you test for bounding-box collsions first, then if you get one, you the check for pixel-perfect collisions?

Best of both worlds.
From,
nice coder

that's what games tend to do. grab the overlapping rectangular area, then check the bitmaks.

If performance gets to be a problem, prioritize. Gunshot collisions (player to AI and AI to player) should be pixel-precise whenever possible. AI to AI gunshot collisions can be less accurate because the player probably won't notice. Object-to-surface collisions (like testing traps, floors, etc.) can generally be done with bounding boxes without any real problems, and in fact trying to do pixel-level collisions for floors etc. can be problematic.

Also, if you use techniques like alpha-blended sprites, you can construct a binary collision mask based on the sprite's basic shape, and do pixel-level tests on those masks instead of trying to handle alpha regions and all of that.

Again this is only really useful if performance is a problem. If you're getting decent performance and framerates with a more brute-force approach, and you don't need the extra cycles for anything, you can safely be lazy and not mess with all this [wink]