   angles and movement(math)
  Ok, I'm terrible at math.  Actually, I'm pretty good at math, but I am terrible at applying it to different situations.  What I have is a 2D game with rotatable sprite that the player moves around.  There's more to it than that, but this is the part I am having trouble figuring out.  At angles other than 0(positive x), 90(negative y), 180(negative x), and 270(positive y), how do I figure out what my Δx and Δy values should be based on the angle the sprite is facing.  Like my Δx and Δy value for cardinal direction(north, south, east, west) is 5, but inbetween those directions it's going to be different so as to maintain believable motion.  So how do I figure out the inbetween values? Thanks.-AJ   
  It is not that hard. First, determine the canonical direction of the sprite. That is, which way would it be moving if no direction changes have occurred? This will be aparent from the sprite image. Let's assume that the sprite shows a car which is facing upward (i.e. north is the canonical direction). Then the canonical direction vector is d = (0,1).You have already stated that your movement is of magnitued five. This gives the velocity vector according to v = 5 * d = (0,5).Now we must incorporate the sprite's rotation. Let's call this rotation r. You can compute the result of rotating a point around the origin by the following formula:x' = x cos r - y sin ry' = y cos r + x sin rSo, to find the actual velocity, i.e. with the right magnitude and the right direction according to sprite rotation, we compute:vx' = 0 cos r - 5 sin r = - 5 sin rvy' = 5 cos r + 0 sin r =   5 cos rThis is the vector that specifies the right movment. So you can now add (vx',vy') to your position to obtain the new position. You may want to include a timing factor to achieve frame-rate independent movement. Good luck.Greetz,   Illco;  Thanks.  I haven't implemented it in code yet, but it looks easy enough to understand and implement.  Will let you know how it goes and/or if I have any other questions.-AJ   ;Quote:Original post by u235Will let you know how it goes and/or if I have any other questions.Always good to hear something back; questions are welcome. Illco;  I didn't put it in the game yet, but I wrote a little test program for it and it worked beautifully.  Thank you.  However, I do have a question, not related to the math, though.  I am using Allegro and the rotate_sprite() funtion places the sprite and rotates it with one call so while the sprite is moving it will have to re-rotate the sprite every frame, even if the direction hasn't changed.  Will this be a performance issue?  I know it will take more CPU time due to calculating the rotation every frame, but will it cause a lag? Thanks.-AJ   ;  I'm not much into allegro, but I'm confident it won't. It is actually very common in games/engines to store the components (position, rotation, scale) separately and when rendering computer the complete transform on-the-fly (this essentially what Allegro does I suppose). So unless a completely new but rotated sprite is computed (actually allocated and copied and such), there is no problem. If this is the case, though, you'd be better of pre-computing a number of rotations and selecting the (approximately) right sprite depending on the current angle.Illco   ;  Cool, thanks.  I didn't even think of pre-computing the rotations and just using approximation.  It would be easier to code that way, too.  Not much, but a little easier. Thanks.-AJ   