Wow, it really seems like polygonal collision detection (and response; I'm guessing) is the new 'fad'. EasilyConfused has been playing with it as well, and I've also been working with it (although I haven't mentioned it publically) for the last couple of weeks, with regards to physics. Seems like only a while before that we had the 'random content' fad, where you, Programmer16, and myself were working on games that focused on random level generation. I wonder what's next? [grin]

Oh, and where's that networking post on FoT that you promised me? [sad]

Mind elaborating on why this is evidently extremely useful in your ubar new project? It's a neat feature and all, but unless you guys are making a huge departure from your previous style, it's nothing you couldn't do without.

Lol, I can't wait until the MMORPG fad[wink]

As for the FoT networking stuff, we never really had that implemented to the point of us playing games over the net, before we scrapped the feature, but I would be more than happy to get a "whats the better way" correspondence going if you'd like[grin]


Well, it Angels 22 and FoT, all the objects are small enough that we could get away with simple AABB's and bounding spheres, but with our new project, the relative scale between the smaller ships and the large ones is so large that using those old methods would result in some annoyingly sloppy collision detection.

For our new project we just outline each ship with a polygon, and then no matter how its rotated or scaled, the polygon will still match up with the ship.

I hate to be a git, but I'm reasonably sure this doesn't always work for polygons (eg, for two polygons where the lines intersect but have no points inside each other, think of two really long and narrow triangles crossing near their narrow ends and you'll find an example)

I had to do something similar at work recently (though it was with Mappoint rather than something fun like a game), and so maybe what I found will help you out.

The method I used in the end was the Separating Axis Theorem. It works by projecting each side of the shape onto a 1d plane and checking for intersection there (if you like I will find you a link later). This seems to work pretty well, but there are a few caveats. Firstly, things get a bit complicated when you have complex shapes (though I doubt you will in a game, so don't worry about this). Secondly, the shapes you are testing have to be convex. To achieve this, you can either limit your collision boxes to be convex and just use them as is, or you can break them down into a set of smaller shapes and test each shape individually. Triangles are always convex, but you gain performance by using fewer, larger shapes

With what you have, you could also add line intersection tests in addition to your point tests, which would tell you if the polygons intersect. However you would lose the knowledge of which point caused the intersection, necessary for your physicsy stuff. I remember seeing how you do this though, I think the basic idea was that you project the polygons along the vectors that they are moving, which gives you two 'fat' lines, factor in their speeds and based on that see if they will intersect. This method is also good for slow computers, since with your current method the accuracy of the collision detection is dependent on the framerate of the game, and a slow computer might miss a collision completely if in the time between frames one object has passed right through another

I think that is mostly correct, hope it helps!