> The real problem is collision response in a way, rather than collision > detection. Consider a situation where you want to place a ball at a precise > spot on a surface. You grab the ball, and move your pointer into the > surface. Then you want to slide it left or right because it's not right > where you want it. Now, since the ball is already touching the surface, if > the collision response is something like 'if collide(ball, table): > dontmove()' then you can't slide the ball, you have to pick it up off the > table and move it. That's what I mean by sliding along a surface.
centertable is the 3 sprite centerring is the 2 sprite 'if collide(ball, centertable) and not (ball, centerring): moveBallPerfectCenter() dontMove(True) Easy fix, more than one sprite. Lets see if I can do this with ascii. 11111111111 11222222211 11223332211 11223332211 11222222211 11111111111 Ok so you have 3 base sprites plus the moving one. If it is only on 3 you know you are in the center. If in is on 2 and 3 you are close if 2 and 1 not so close if 1 then not at all close and if not on any then it is, well, not there. If it must be perfectly centered then you have the point that is the center point and the point that is the center of the object and test the distance with the python hypot command. For imperfections make the thing that goes in the center a bit smaller that the 3s. Pixel perfect collision project. If you need more speed, I bet someone would C code it for you. I have not tested it out. http://www.pygame.org/projects/9/207/ > A demo is worth a thousand words, so I've attached a little demo using just > circles which almost works if you want to play with it. Just python > circles.py There's some floating point issues so sometimes the circles end > up inside each other, but it mostly works and shows what I'm after. > > --Mike Circles is really cool. What does vectors do? -- Douglas E Knapp http://sf-journey-creations.wikispot.org/Front_Page