I was just contemplating how collision detection works with objects moving at different speeds. say a bullet (1pixel) had a velocity of 1 (pixel per frame) in this case you can just check if the bullet is about to collide with something on each frame by checking if the next pixel ahead is solid... no problem right? now what if we gave it a velocity of 5 pixels per frame? in this case every frame, it is picked up and moved five frames (in whatever direction) so therefore it is skipping 4 pixels along its path. we don't want this because what if there were a solid wall in those 4 pixels it would go right through it (instead of bouncing, exploding, etc...) ill draw an example of what i mean to make it more clear: so what can we do about this? i think it would work, to on every frame, check the five pixels ahead of the bullet for solidity before moving it.. but would that be too slow? is there a better way to handle this? anyone have some insight on this? thanks jakerrz [edited by - jakerrz on November 3, 2002 12:29:01 PM]

Like Qatal said: treat your collidable objects as vectors, and test collisions based on the space swept out during movement.In this case, you could create a line segment that represents the movement of the bullet, and a line segment for the wall. Then you check to see if the two line segments intersect. If so, their intersection point is where the collision occurs.

Note: this technique does not work well when you try to solve more complicated systems, such as polygons that can rotate. However, it will model what you are trying to do just fine.

A simple bresenham-based pixel checking approach to collision detection will likely be faster than solving for the intersection point, however you need to profile to be sure.

One advantage of the vector method is that you can have non-integer velocities/angles/positions.

kool that sounds great
I''d like to see that
Thanks!!

my email address is:
jakerrzero@hotmail.com