   [solved]How prevent lag to be of negative consequence to pixel exact collisions?
  The only ways I can think of are: a, prevent the lagb, don't make the collision pixel exacta, is only possible with a bit of dirty work (instead of creating all units at once, create them with a timer only every x milliseconds) and might not be so everytime I have this problem, b, is unacceptable.I'm thinking that this must be a standard issue with game programmers, maybe someone could enlighten me? Here is a more elaborate (for ease: 1-dimensional) explanation of the problem:Suppose unit x has position 5 and is moving with speed 1. Now I want to check when unit x has reached 10, and then stop it. Of course everything in the game is time related, thats why speed is multiplied with *timePassedSinceLastFrame.However, if lag occurs, that time multiplied with speed 1 is possibly higher than the difference between position and destination.I'm checking for a "collision" like this: unitx.position += 1 * timePassedSinceLastFrame;if ((abs(destination.position - unitx.position)) < 1)   stop unit xTherefore the new position might be 12, and this means that the unit will never be stopped, since the difference between destination and position was never smaller than 1.[Edited by - Meai on June 15, 2009 4:45:44 AM]
  Yeah, that is an annoying problem, especially in variable timestep. Even with fixed timestep, you can run into it if the object is moving fast and the stop radius is small.For fixed timestep, I would just check if the distance to the destination is less than the length of the velocity vector, and if so, set the velocity to go right to the destination. Like,vector delta = dest - position;if (delta.lengthSquared() < velocity.lengthSquared())    velocity = delta;But for variable, it would probably be easiest just to slow down as you get closer to the destination. Or another solution could be to keep track of which side of the target you're on, and jump back to it if you go past. ("side" being relative to the direction you're moving. Imagine a line perpendicular to the velocity vector, passing through the destination point. You can check which side of it you're on by whether velocity dot (dest - position) is positive or negative)   ;  Why not test then iterate? as apposed to iterate then test.You know unitx.position is changing by that a certain amount. Is there a reason why you cant figure out where it is going to be and then ask the question does it fit the rule that i want to apply?Yes... great put it there.orNo... well its gotta stop.;Quote:Imagine a line perpendicular to the velocity vector, passing through the destination point. You can check which side of it you're on by whether velocity dot (dest - position) is positive or negative)Very nice, I just tried it all on paper to be sure (:P), all works out. (am not seeing why you mentioned the perpendicular line though)Quote:Why not test then iterate? as apposed to iterate then test.You know unitx.position is changing by that a certain amount. Is there a reason why you cant figure out where it is going to be and then ask the question does it fit the rule that i want to apply?Wonderful, that will work even easier!   