Collision detection in Cocoa

Mikuro

Mikuro

Crotchety UI Nitpicker
I'm trying to create a simple 2D sprite engine (more as an exercise than anything else, really), and I need some way to do collision detection. How should I go about determining if one irregularly-shaped image overlaps another? I think this is easy to do using QuickDraw regions, but I'm trying to keep it all Cocoa. Quartz doesn't seem to have any similar functions. Seems like Quartz has a bit of a "screw bitmapped graphics" philosophy. :(

I guess I could check each individual pixel's alpha level and compare it to the corresponding pixel in the other image, but I imagine it would be way too slow. Am I wrong?

While I'm on the subject...should I be using Quartz at all for such a thing? Would I be better off basing the whole thing on QuickDraw? I know I could also use OpenGL, but...I don't wanna (yet). OpenGL scares me.
 
dude, OpenGL is your friend, hardware accell will benifit you so much. It is much faster an has built in functions for altering graphics.

Try doing some searching on google for collision grid, that is what one of my friends said he was using in his 2D engine (implemented in Java). I am sure that it doesn't matter what language you are using, you should be able to implement in whatever you want to.
 
Thanks for the tip. I've never heard the term "collision grids" before. However, I'm already doing something along those lines (great minds think alike?). Unless I'm missing something, it's usefulness is in narrowing down the number of objects that MIGHT collide with your object rather than actually testing if two objects collide. i.e., if you have 10,000 sprites, it's too inefficient to test every sprite against every single other sprite for collisions, so you break them down into a grid, and test against every sprite in the same grid zone(s).

But it doesn't help me actually check if two images really do collide based on their individual bitmapped shapes. The best I can do is figure out if their bounding rects collide, using NSIntersectsRect.

Oh, and as for OpenGL, for now I want to stay away from it for two reasons: On older machines with unsupported graphics cards, it's much slower that Quartz; and I'm wondering if Quartz will be faster in Tiger because of Core Image. Oh, and also I'm lazy. Can't forget that.
 
Thanks, guys. I implemented it by using NSBitmapImageRep's -bitmapData method, and accessing the bytes directly. If any of the corresponding alpha bytes from the two images are > 0, then they've collided. Not too hard to set up, but I'm still surprised there are no built-in functions for this kind of thing.

The downside is that it limits the kinds of images I can use. I had some problems with cached image reps (since they have no -bitmapData method). And I don't know what would happen with images that had more than one imageRep. For now I load my data from PNGs, and do conversions to bitmaps if necessary, so I think it's alright.

[edit: Oh yeah, and it's gonna make working with scaled images a pain... And I'm scared to even TRY implementing rotation now, although I can live without rotation.]

My overall framerate more than doubled by forcing bitmaps rather than cached images, too. So I guess it's a good thing. :)

I'm also a little worried that some bitmaps may not use the RGBA format. The documentation isn't really clear. Anyway, it works with my PNGs, and I'm perfectly happy saying "screw everything but PNGs!", at least for now.

I'll post my code if anyone wants it. But I'm not confident it's bug-free (and I seriously doubt it's as efficient as it could be).
 
Mikuro said:
Oh, and as for OpenGL, for now I want to stay away from it for two reasons: On older machines with unsupported graphics cards, it's much slower that Quartz; and I'm wondering if Quartz will be faster in Tiger because of Core Image. Oh, and also I'm lazy. Can't forget that.
Click to expand...

This is true, but you have to consider this: Under Tiger, you are guaranteed to have a supported video card in the system. However, it is still pretty easy to make a really speedy Quartz game, unlike OpenGL developers in the shareware scene currently. (I made the argument that the current style of setting up OpenGL resulted in needlessly sub-par performance on machines not capable of keeping up, as NSTimers are awful things to be using for render timing) There are ways to get really good performance out of OpenGL on all manner of systems, but few people seem willing to put in the effort required to make it happen.

My advice? If you are just doing 2D, stick with Quartz, it is much easier, even though the 'lack of a 3D card' isn't a huge issue anymore (heck, I even owned a Lombard).
 
You must log in or register to reply here.
Back
Top