collision detection

This topic is 4721 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

i have 2 sprites that i can cause collision detection with windows api . when the 2 rectangles of the sprite collide then it hits. the problem is the rectangles collide not the actual sprites within the RECT just the RECT boundaries. how can you do this with directX and c++

Share on other sites
Speaking as a new very inexperienced Game Programmer (and also not used C++ or DirectX), i'm developing an Air Hockey game in C# and i had this exact same problem with my paddles colliding with a puck.

Both my paddles and puck were circular images loaded in but they were in rectangle dimensions.

My recommendation would be: if these sprites are circular, consider getting the radius and just trying to test for a collision against them.

Otherwise, i can't help you... sorry, not very experienced in the area just yet!

Best of luck with it anyways!

Squiller

PS - by the way, how i sorted my problem in the Air Hockey was i drew the puck / paddles are two different color ellipses... not exactly the most graphically pleasing but it works nonetheless.

Share on other sites
you could do per pixel collision detection, but really, thats not worth your time as its a fairly slow algorithm, instead, check out oliii's tutorials on the separation axis theorum(test?) With that you will be able to collide convex polygonal shapes in 2d (it can be easily expanded to 3d but it becomes unwieldy in 3d) just member search for oliii.

hope that helps
-Dan

Share on other sites
For fast and accurate collision detection, I recommend taking a look at this article: http://www.magic-software.com/Documentation/MethodOfSeparatingAxes.pdf

Do be aware however that the method of detecting intersection discussed in said article pertains only to *convex* polyhedra. Although it can be done, I recommend against trying to extend the algorithm to work with concave objects.

http://www.d6.com/users/checker/dynamics.htm#articles

It discusses rigid body dynamics, the fancy term for determining what happens after a collision. As far as I know, all the equations are correct (though I haven't looked over the article in much depth).

Also, one more quick tip: always use Verlett integration instead of Euler: it's much more accurate, and will almost definately yield better results.

Hope this helps.

Share on other sites
i take it there is no standard or function i can use for collision detection

Share on other sites
Quote:
 Original post by jagguyi take it there is no standard or function i can use for collision detection

Unfortunatly not. Infact there isn't even a standard way of implimenting most of the collision detection algorithms out there. Everyone seems to have their own version and they all seem to be poorly documented with annoying ommisions that make it quite hard to get your foot in the door. This is the hardest part about game programming ... collision detection and physics in general are hard like nothing else I've met so far. However if your after sphere vs sphere is pretty easy (google for pool phyics or something like that), and boxes isn't too bad either. If your after pixle perfect or complex shapes then your in for a steep learning curve and I suggest you simplify what your after to something like circles or boxes. Good luck!

Share on other sites
This is what I've done in the past for the problem you are having...

I realize that pixel-perfect collision would be the most "perfect" way to go but like said above... its a slow process. What I would do if I were you is this:

1) Find the boundaries of your sprite and store in a rect (which you already have)

2) Make a separate "collision" rect that is possibly... lets say 80% of the original rect

3) Then test collisions against the "collision" rect, not the full widths and heights of the sprites

Ok, this still has problems with the corners BUT... the graphical imperfections are smaller than before and its still very fast. But, still look into collision detection with axes and all that jazz..

Oh.... and this may sound stupid BUT...
Make sure that the bounding rects are as close to the "actual" sprite as possible... otherwise the 80% thing won't really help..

If you want more help on this private message me and I'll help ya' out some.

Good luck and I hope this helps :)
toXic1337

Share on other sites
Here is an idea for all you gurus who have time on your hands. Or you can
wait until I get sometime on my hands to do it. I am mainly interested
in 3d but the principals would work for 2d. It is kind of reverse 3d
modeling. Lets say you were going to model a car. You think of some
basic primitives (cubes, spheres, etc.) that put together come close to
the volume of your object. I would think you could come up with a
generic routine that could come up with a number of primitives given
a tolerance in volume error that could approx. the volume of each
object in you game. Than for collisiion detection you check amoung
the these primitives instead of the actual objects. I am talking 2 or
3 primitives per object here. To apply this for 2d. You would use
circles and rectangles to approx. your area of the pixels in your sprite.
This routine would not be worth doing for one program for you could do it
by hand. But if someone could come up with a generic 2d,3d version you
would be famous!!!!

Share on other sites
If 2D == True Then     http://www.kuhnstall.de/tutorials/dx9sharp6.htmlEnd If

Share on other sites
Susan-gt:

I think that is how most optimised collision systems work, they take rough shapes that are easy to compute the collisions for and only when those collide do they use the actual accurate method.

My favourite at the moment is Oriented Bounding Boxes.