Hm, so it would appear that the boards ate my last post so here goes again. Can you give me a little more info about the actual structure of your objects, like how you stored your line segments? I have seen a lot of articles on the web that say how to collide vs a line but skip what the actual format should look like. I like your bounding- shape idea, it makes a lot of sense. My other pet idea was to use actual equations of lines to represent the walls, but it looks like it is getting ugly very quickly. Does anyone have any thoughts / experience with this? It seems like it would be quick as you would only have to do one test per collidable structure, but then you would have to take the derivative of that line on the fly (or, perhaps, pre- compute it) to figure out the reflection angle and what not. Not to mention I have no idea how to figure out the equation of an arbitrary squiggle. Thanks again for the help.
-cheers On Nov 30, 10:02 am, Phred <[email protected]> wrote: > 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
