> Without is ok In that case, all you need is a standard line segment-moving point collision function. Then to detect collisions between two boxes, you can test each vertex of one box for collision with the edges of the other, and vice versa. There are various optimisations you can do, but that's the essential idea.
The other way to do it is to think in terms of matrices. I like to think of a box as a unit square which has been transformed by some standard Transform matrix. An axis-aligned box with width w, height h and top-left corner at (x,y) is just a unit square with corners (0,0), (0,1), (1,1), (1,0), transformed by the Matrix (w,0,0,h,x,y) (you can include rotation info here too, of course). To get a collision between the box and a point at (p,q) moving along the vector (s,t), you can invert the matrix and apply it to (p,q) and (s,t), getting new vectors (p',q'), (s', t') [actually, you shouldn't apply the translation part to (s, t), just rotation and scale]. Finding collisions between these vectors and the unit square is a lot easier than with the arbitrary box. Sorry, no code here (I'm sure others can help, but I don't have the Flash code to hand), but maybe this might give you some ideas. Danny _______________________________________________ [email protected] To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
