![]() |
|
Sometimes collisions work, sometimes they don't. - Printable Version +- iDevGames Forums (http://www.idevgames.com/forums) +-- Forum: Development Zone (/forum-3.html) +--- Forum: Game Programming Fundamentals (/forum-7.html) +--- Thread: Sometimes collisions work, sometimes they don't. (/thread-4307.html) |
Sometimes collisions work, sometimes they don't. - t3knomanser - Apr 28, 2006 11:57 AM I'm building a maze game controlled via motion sensors. Think that old tabletop Labyrinth game. When the ball strikes a wall at a low speed, it stops, but if it's at a high speed, it passes right through. This also means that if the ball has stopped, I can tip the laptop farther, and it will eventually go through the wall. The collision detection is in a controller class that has a reference out to the CustomView used for rendering. The collision detection is called after the new dot position has been figured and the screen has been refreshed. There also seems to be a problem when two walls intersect- I can sometimes sneak the ball through the corner, although this could be related to the current problem. I've been banging my head against the wall for weeks on this, so I'm throwing it up here to see if anyone has any thoughts. I'm obviously missing something really butt simple. But I've spent years avoiding game programming for just this very reason. Code: Code: - (void) collideDot:(Dot*) d withWall:(Wall*) wSometimes collisions work, sometimes they don't. - unknown - Apr 28, 2006 12:12 PM Quote:When the ball strikes a wall at a low speed, it stops, but if it's at a high speed, it passes right through. if you were doing point against a wall (line in this example) collision for example, intersect the line from the point's origional position to the current position with the wall. I would recommend cleaning up your code style its awfuly hard to read the collideDot function, and when things are clearer your problems will probably jump out at you
Sometimes collisions work, sometimes they don't. - t3knomanser - Apr 28, 2006 12:23 PM unknown Wrote:I would recommend cleaning up your code style its awfuly hard to read the collideDot function, and when things are clearer your problems will probably jump out at you This is loosely based on some tutorial code I dug up. I'm rewriting it to use some temporary boolean variables instead of those crazy ifs. But that is the algorithm I'm using. Sometimes collisions work, sometimes they don't. - ThemsAllTook - Apr 28, 2006 12:35 PM It looks like you're using a simple intersection test to check for collisions. For fast-moving and/or very small objects, this will not work reliably. Your moving object is probably passing completely through the wall between two of your collision checks, in which case an intersection test at both points would return false. What you'll need to do is somehow take into account the movement of your object between the two positions at which you perform your collision tests. Since you're working with a sphere, one thing you could do is extrude it into a capped cylinder, and test intersection between the cylinder and the walls. Another option would be to do multiple intersection tests per frame, each one working with a small enough timeslice that the object doesn't move far enough to pass completely through the wall. I sympathize with you, because this is a somewhat difficult problem... In my free time, I'm working on implementing something very similar. I may write a tutorial on it at some point if I'm successful. My time-based animation tutorial may also be of some use to you: http://www.sacredsoftware.net/tutorials/Animation/TimeBasedAnimation.xhtml Sometimes collisions work, sometimes they don't. - t3knomanser - Apr 28, 2006 01:01 PM What I've done to fix the go through walls is capped the ball's speed lower, and increased the refresh rate- it's still using one-frame-per-update, but the updates are going a lot faster, and the graphics aren't really heavy, and the ball just moves less distance per update. It balances out. It still has a flaw where walls overlap- the solution that I'll implement in the near future- I'm going to make the walls not overlap. Ever. Sometimes collisions work, sometimes they don't. - Iceman - May 13, 2006 03:00 PM Here's some good links for collision detection: http://astronomy.swin.edu.au/~pbourke/geometry/pointplane/ This explains what A x + B y + C z + D = 0 is: http://astronomy.swin.edu.au/~pbourke/geometry/planeeq/ This explains how to find the exact point that it will be on the plane at the bottom of the page http://www.lighthouse3d.com/opengl/maths/index.php?planes To turn the plane into a square just use two more planes that intersect the first one. Then use A x + B y + C z + D on the intersecting planes to find if the point is within the square. This is a little more complex than you really need but it finds the exact place the point will pass through. |