collision detection
Author
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++
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.
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.
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
hope that helps
-Dan
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.
For collision response, you might give this article a read:
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.
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.
For collision response, you might give this article a read:
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.
Quote:Original post by jagguy
i 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!
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
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
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!!!!
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!!!!
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
