Skip to main content
GameDev.net gamedev.net
🔒 Locked

Collision detection

Started by NightZero Jan 3, 2003 at 3:40 PM 3 replies 300+ views
Original Post
NightZero
NightZero
I would like to do a pixel perfect collision detection between two sprites. I have read all the tutorials i can find, and I''ve got a grip of the theoretical basics. I make a overlaping rectangle och the two sprites when they overlap. Then I scan the overlap rectangle for pixels of both sprites that is not transparent. _But_ how do i access the pixels in a directdraw7 surface? Are there any good functions that are easy to use? I can''t find any code examples in C++ for DirectX (8.1)... Regards, Mattias
Pseudo
Pseudo
Why do pixel perfect. Almost no games do this because it''s slow and unnessesary. But if you really want to do it, make sure your DX surfaces are in system memory (otherwise it''s even slower) and use surface->Lock() to get a pointer to the surface memory.

I suggest you just use bounding boxes...if you really want more accuracy, then (when you load the graphics!!!) scan through the pixel data and calculate multiple bounding boxes that fits the data better than a single. This will be much quicker and wont require locking the surfaces.

Does that make sense, or should I explain further?
NightZero
NightZero
Ok, that make sense... But I dot quite get the part where you describe multiple bounding boxes and scanning pixels...

Quoting:
...if you really want more accuracy, then (when you load the graphics!!!) scan through the pixel data and calculate multiple bounding boxes that fits the data better than a single. This will be much quicker and wont require locking the surfaces.
...

Regards,
Mattias
Pseudo
Pseudo
That''s exactly what I mean. I''d keep the total number of rectangles per sprite down to 5 or so, because then, you need 25 rectangle comparisons (around 100 maximum comparisons) per sprite. Now, that seems like a lot, but doing it per pixel would require the width*height comparisons, and that is likely to be in the many thousands (ie, 100x100 sprite would require 10,000 comparisons max). And that will kill performance.

I did something like this once, and the collision detection went like this.

First I manually made subbounding box''s for each sprite frame (so the collision is based on animation), but this could be done computaionally at runtime as well. Then, each frame for each pair of sprites I would compare the two sprites overall bounding box (this is a rough detection). If they don''t collide, go on to the next sprite. If they do, continue. Next, for each sub-bounding box, check it agains each of the other sprites sub-bounding box, if you ever get a collision, then abort because you don''t have to check the rest.

This will give you a quick and accurate 2d collision detection model and now you only have to worry about collision response.

Hope that helps.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.