I've done similar stuff in the past and I've found the best way is to use a multilevel approach. First have each object have a radius such that it can tightly encircle the whole object. Then do a broad range sweep of of collision tests using circle-circle colission tests. This is basically using the center point of each object and taking the distance between them then checking that distance against the sum of the radii of each object. If it's less, they've collided and you can flag them as such. THEN you can test each flagged collision to see which parts actually intersected using line vs line collision methods.
On Nov 29, 2:58 pm, Brian <[email protected]> wrote: > Hello, > > I am currently working on a collision detection routine for an Android > based game which is capable of handling complex concave curves in 2D. > I use complex in this post to describe any non-trivial, arbitrary > shape (beyond circles, squares, etc.). My problem is that all of the > various methods I have come across are either too simplistic to be > realistic or too complex for a cell phone. At the moment I am > favoring a tile-based scheme but I am having problems figuring out how > to do this with convex curves that span several tiles and may have > several line segments per tile. I gave some thought to representing > the curves mathematically, with each tile being an interval of the > function, but there will likely be points where the curve doubles-back > on itself (think the big loop at the top of a pinball table that > brings the ball all the way around the table and back the direction it > came). My questions boil down to: > > 1. Does anyone know of a way of hit testing a given simple shape (eg. > a circle) against a concave series of line segments (shapes beyond > circles can be figured out from there) beyond just a Boolean result? > > 2. What is the best way to represent large, complex shapes > programatically? I am currently favoring an XML file describing my > levels and the objects in them with shape/position/physics/etc. data > to be parsed in during load time. > > 3. Is there an altogether better way of doing this beyond line > segments? > > The one saving grace in this conundrum is that I know the vast > majority of the objects are stationary with, at most, three or four > (usually one) dynamic objects moving around. Thanks in advance for > any help. > > -cheers -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
