Hopefully that made sense, it's a little late over here. In case of a collision, the object's final position will be that of the collision point. Since it sounds like all your walls are either parallel or perpendicular to each other, only one more test will be necessary as the second line's movement will be either parallel or perpendicular to any wall as well. One more line-line collision test can be performed using the vector between your first collision point and your final position. Take the point of collision and form a line between that point and your intended current position and then project that line on to the wall to get your final position. With regards to your problem, what I would do is take your velocity vector for the current frame (the vector that goes from your previous position to your intended position) and do a line-line collision test. Converting your angle to a vector is time consuming as trigonometry functions are slow in comparison to just storing the direction or velocity. I'm going to second the notion that you use a velocity vector instead of an angle. Or maybe just randomly: ensuring that movement continues if possible is important, but its direction is not since the player will get the sprite unstuck from corners ASAP, or the enemy unit's pathfinding (which is unlikely to run into walls unless it really wants to) will decide to go somewhere rather than bouncing arbitrarily. The only tricky part is figuring out some V2 that doesn't point into an obstacle if your walls are segments you could simply choose between turning left or right along the segment according to different criteria:ġ) in a corner and already following a wall, away from the corner (along the other side) Ģ) if clear on both sides, in the same direction as the projection of V or other "good" direction along the wall ģ) if the desired direction is perpendicular to the wall, randomly. Subsequent collisions can be treated in the same way, until the whole timestep dt is exhausted stopping at some arbitrary number of iterations isn't useful. In a timestep (dt seconds) the representative point moves at speed V, trying to go from location P to location P+V*dt if the segment between these locations intersects walls you can find the position Q=P+V*t1 of the first such intersection, figure out a new movement speed V2 and move the entity again, from Q with velocity V2 for a time dt-t1. "Movement vectors"? Shouldn't you use true velocities? If anyone has done this before or has seen a good tutorial on something like this it would be really helpful, thanks. I'm working with 360 degree movement, so i've got X and Y movement vectors if that helps. Maybe this could be done by recursively calling the algorithm with the new point you're moving, and returning no movement at all if it goes more than a second or third sub-call. By putting the coordinate of the testpoint into the equation and using the actual line slope m, the y-intercept of test point p called b (p) should be equal to that of the line in case the test point lies on the line: b (p) p.y - m p.x. You don't want to run up against one wall that bends inward then end up in the middle of another wall. To check if the test point p lies on it, this equation can be easily used. I suspect an easy pitfall of any such algorithm would be corners, as well. Perhaps it should it be a projection of the movement vector on the wall?Ĭ. How much should i move along the wall given the wall facing and character movement vectors. How to set the sprite's position so that it'll be on the permiter of this wall (Note that it'll always be a straight line). As the sprite runs north against the wall, he should start moving northwest along the wall, not just stop running as soon as he hits the wall because you can move where you're trying to go.Ī. that is, say a sprite is moving north, and there's a wall facing southwest. But what gets me is the "clamping" movement to the wall. Well, that's not quite the problem i can tell if a dot crosses a line easily enough. So its really just point and line intersections on a 2d plane. Meanwhile the 2d sprite's position is represented by a point. the 3d world is really an evenly spaced set of vertices in 2d with height values, and the Z doesnt matter in this case. If there is a collision, uA and uB should both be in the range of 0-1.I've got a 2d sprite moving around in a 3d world. With this example, you'll be able to build a super-sweet sword fighting game! (Or reboot one that never got finished?)
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |