• Status: Solved
• Priority: Medium
• Security: Public
• Views: 236

# sine/cosine inaccuracies

Hi there everyone.  I've been using the C++ sin() and cos() functions to get the x and y coordinates from a direction and speed variable.  Now, I have noticed that when I use these and the speed (float) variable is fairly low (0 to, maybe, 50 ish) the functions behave very strangely.  First, here is the code I use:

car.x += (int)((speed * cos(direction * 3.1415926535 / 180)) / SCALE_FACTOR); //everything reduced
car.y += (int)((speed * sin(direction * 3.1415926535 / 180)) / SCALE_FACTOR); //by a factor of 15

car.x and .y are integers; I cannot change that.  Direction is a float between 0 and 359.99... and speed is a float from 0 up.  the SCALE_FACTOR is currently 15.

what happens is this.  If the angle is far from pointing left,right,up, or down, at low speeds my car moves in a sort of zigzag pattern, going first left, then up, then left, then up, until it reaches a certain speed where it then goes normally.  If the angle is close to those four angles, at low speeds the car simple goes straight left (or up, or down, or right) until it reaches a certain speed where it performs normally.

If i'm not being clear I can email you the program in question so you can look at the effects yourselves.  Thanks in advance.
0
GabeSmed
1 Solution

Commented:
Could you give a exactly pair of speed and direction that can let the car move in zigzag?

Maybe you should add 0.5 to the result of cos or sin, things will be better.

like this:

car.x += (int)((speed * cos(direction * 3.1415926535 / 180)) / SCALE_FACTOR + 0.5);
0

Commented:
hi ,
yz is right , I 'll explain what is that mean :
casting problem causes the calculated velocity (speed) to jump from one side of a certain integer to the other .

to avoid such behavior , add 0.5 to the cosine like
cos(direction * 3.1415926535 / 180)
change to :
[cos(direction * 3.1415926535 / 180)+.5]

in addition change 180 to 180.0 , in some compilers it maybe helpfully.

Talmash
0

Commented:
If you're going to add 0.5, you'll probably want to convert with floor instead of trunc
But at low speed, with the car moving <3 steps per move, there won't be very many exact angles available in integer coordinates.
Do you just want to move toward the closest angle possible?
Do you want the angle to average out over several moves?  (which could mean zig-zaging back and forth across the ideal line) Or do you prefer a consistent error?
Would you prefer to allow a greater error in the speed in order to reduce the error in the angle?
Do you want to favor movment near cardinal directions?
0

Commented:
hi again ,

change 15 to 15.0 ( also like 180 -> 180.0 )

Talmash
0

Author Commented:
Talmash, your answer was really clear and explained to me why the zigzags happened, but I have to give the points to ozo because his statement 'integer coordinates' got me thinking to actually figure out a solution.

All I did was make two doubles for true_x and true_y and every frame cast them into the integer x and y.

Thanks everyone!
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.