Does anyone have some good logic (not necessarily code, but if you happen to have to urge to give C++ code snippets, be my guest) for collision checking? I know about the IntersectRect function from DirectX, but using that isn't enough. I was planning on moving the player back to a previous position if there was a collision with an enemy, but that wouldn't really work, because it is possible for a moving object (like an enemy) to have a collision with the player, in which case the enemy should move back, not the player. And I haven't though about non-moving objects. This may be simpler than I think it is, since I'm kind of tired right now, but if anyone can pitch in with their idea for this, it would be nice.
CoolGamer48 65 Posting Pro in Training
MattEvans 473 Veteran Poster Team Colleague Featured Poster
This is good reference, http://www.gamasutra.com/features/19991018/Gomez_1.htm there are collision tests for different pairs of 3D objects ( see contents box on the right ). The tests would work in 2D, but, there are even simpler versions of these tests for 2D.
'Separating objects' that have collided is theoretically simple - calculate the magnitude of the velocities of the two objects before the collision, make them proportional ( i.e. turn the velocities into positive normalized weights ) hold on to those for a second =P. Now, calculate the intersection vector of one of the objects into the other object, that's simple, since most static collision tests for convex hull types give you this information for free. Translate both objects by their normalized velocity weight multiplied by the intersection vector, or by the normalized velocity weight times the intersection vector times minus 1; depending on which of the two objects it is, and depending which way you measured the intersection vector.. that works well for immediate separation of illegally intersecting objects. Alternatively, never put objects into intersection - keep them separate by checking that they can move into space before you move them, or use both methods.
Do you have grid/tile based space or not? If you dont, I suggest using some kind of pairwise pruning before checking objects - i.e. not checking objects that can't collide.
All in all, it's quite a complex subject, but there are many simplificiations. In 2D tile based space, it's alot easier because a 'collision' is just attempting to enter an occupied tile.
If you use broadphase pairwise pruning in 3D space, it reduces computational overhead, but, the tests for pairs of objects can get especially complicated ( in 3D ) if you don't use simplified convex hulls to represent collide-able objects, it gets somewhat more complicated if you want temporally accurate collision detection ( i.e. checking pairs of moving objects ) That said, all tests for hyperspheres are cheap, even if both spheres are moving, even if they're 'moving at the speed of light'.
Ezzaral commented: Very good info. +6
Phaelax 52 Practically a Posting Shark
I saw several potential note-worthy links on collision here:
http://www.yov408.com/html/tutorials.php?s=54
Though I can't be 100% positive this is the right link (proxy at work blocks game-related sites) but I do believe this is the same collision and response article I used to build my collision system in a game. It uses a swept ellipsoid against polygons. It's very accurate, but the article probably isn't for beginners. But I thought I'd share anyway in case you were interested.
http://www.peroxide.dk/download/tutorials/tut10/pxdtut10.html
Also, the NeHe tutorials are often a good source too, just do a google for them.
Be a part of the DaniWeb community
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.