Move it as if you are moving it in one dimension, on a straight line which starts at 0, then calculate each frame where along the line it should be when at that 1D position.
In other words, move it at a speed of 100 uniers per second. Or 5 units per frame, or however you want to move it. Then, each frame, take that distance, and loop through your list of points, subtracting the distance between each set of points, until you exceed the desired distance. Then calculate using the remainder, where the sprite lies in that segment.
This is what my sprite system does in it's path system, except that in my games I needed to allow hundreds of sprites to move along multiple paths, each with thousands of points and line segments. So I optimized it by precalculating the length of each segment when the path is created, as well as the distance each point is at along the line, and storing these in an array. Then I do a binary search of the points until I know the particular segment the sprite lies on. Using a binary search means that even with thousands of line segments, each sprite only has to look at about 8 points on the line to determine which segment it is on. And that means that even with thousands of points on multiple paths with hundreds of sprites moving along them, my framerate doesn't drop.
But you don't need to go that far if you just want to move a few sprites along paths with only a few points. The paths in my game have thousnads of points because I build them using a bitmap, so each pixel bascially becomes a point on the path. (The sprite system just takes whatever paths you give it and uses the optimized code on those paths, they don't have to have thousands of points or be built from a bitmap.)
|
