I started trying to write a game in C# with XNA. The movement is done with an angle that you are facing. I went under the impression that sin(1) == sin(91) (Which Kerm proved false). I keep a look-up table for which direction you should move depending on what quadrant you are in. For instance, if you are in quadrant 2 (top-left in my case), then you are decreasing the X and increasing the Y values. It multiplies the look-up table value by the appropriate Sin/Cos values I get. int Angle is between 0-359 (can be 0 and can be 359), tempAngle is the MOD 90 of Angle. int speed is the speed at which you are moving. piUnder180 is literally 180 / MathHelper.pi, and is used to turn Degrees to Radians.

The main problem I am running into is: when you change quadrants, your character "jumps". I'll include the important parts of my code below if it helps people better than my awful introduction above.

Edit: Actually... piUnder180 = Pi / 180; It still does the correct transformation from degrees to radians though.

Code:

Your handy-dandy calculator will tell you that sin(1) != sin(91) and that sin(181) != sin(271). However, sin(X) = sin(180-X) and cos(Y) = cos(180-Y).

I remember checking on the calculator once, but my memory seems to fail me on this sort of thing a lot (case in point: I figured out on Tuesday that my birthday was exactly 1 week later, and then on Wednesday I forgot that I had figured it out the day before and thought my birthday was one week later, therefore Wednesday.)

I think in this case, I had checked sin(1) = -sin(91), but remembered it the wrong way :/

Edit: So I guess what I'm mainly asking about in this thread is, how do I fix it to work? I'm going to try to think of a way using this new logic :/

Think about the unit circle; sin(1) is nearly horizontal, and sin(91) is nearly vertical. Since sin(theta) is the x-component, therefore sin(1) must be close to 1, and sin(91) must be close to 0, right?

Yes, but unfortunately I don't see where that goes... Unless ...

Do I need to MOD 180 and use that with sin() so that I get it between -1 and 1, and do the same with the Y component and then I can say: screw the look up table?

No, I already answered your question. You know the following things:

0 <= Theta <= 90: sin()=+; cos()=+
90 < Theta <= 180: sin()=-; cos()=+
180 < Theta <= 270: sin()=-; cos()=-
270 < Theta < 360: sin()=+; cos()=-

When the signs of sin() and cos() are equal, return sin(theta%180) and cos(theta%180), with the appropriate signs applied.

When the signs are unequal, return sin(180-(theta%180)) and cos(180-(theta%180)), with the appropriate signs applied.

Woo! Thanks Kerm One of the big problems with it was: I was using Sin() and Cos() backwards x.x For the record, here is my current code:

Code:

That's one of the things that got me in my early projects: sine is arguably more well-known than cosine (and comes before it on the 83+ keypad), but you need to plot (cos(θ),sin(θ)) on the xy plane to traverse quadrants in the right order as you discovered. At least the coordinates are in alphabetical order!

Weregoose, making mathematical mistake? I don't believe it; you're clearly making it up. I too think of the logical order as "sine, cosine" thanks to the keypad, SOHCAHTOH, and other reasons, so (cos,sin) feels "backwards" to me.