Direction of Angles

[kolofsson]

Hello, I wanted to suggest if the angle in SFML should not be clockwise instead of counter-clockwise?

On paper, the X coordinate expands to the right, and the Y to the top. But on screen the Y coordinate is flipped downwards. To use the usual trigonometrical formulas I have to add minuses when calculating or refering to the Y coordinate.

So, in brief: if the coordinates system is flipped, shouldn't the angle be flipped too?

Other case is the measure. SFML uses degrees but the trigonometrical functions in cmath use radians, which makes me store my angle values as radians and then convert them for SFML.

[Laurent]

Y is flipped downwards, but in your game the top of the view is still considered as being upwards, so I think angles are more consistent this way.

About degrees, it's much more human-friendly than radians. Think about beginners who may not be very cumfortable with Pi and trigonometry in general

Conclusion : just write your own function to convert SFML angles to whatever you want

Code: [Select]

inline float ConvertAngle(float UpwardDegrees)
{
    return -UpwardDegrees * Pi / 360.f;
}

[dunce]

Code: [Select]

inline float ConvertAngle(float UpwardDegrees)
{
    return -UpwardDegrees * Pi / 360.f;
}

A little bit faster:  

Code: [Select]

{
    return -UpwardDegrees * 0,008726646f;
}

[Laurent]

I think compilers are smart enough to precompute constant expressions

[tgm]

yes, he is^^

[kolofsson]

Code: [Select]

Y is flipped downwards, but in your game the top of the view is still considered as being upwards, so I think angles are more consistent this way.

Speaking of consistency, if you assume that "an angle increments from X to Y" then the consistent solution would be to revert the angle. Another consistency issue: when reverted, the mathematical formulas work without alteration.

But well, i know it's not a big deal, just complaining, that's what i do best.

[workmad3]

The case for degrees/radians is a fairly old one. In this case, degrees is probably the better case for consistency as SFML seems most closely tied to OpenGL which also uses degrees for angles. As there is a constant conversion factor, the point is fairly moot anyway as it is the work of seconds to write a function that will convert to and from one system to another.
It may be nice if there was an extra 'helper' function for things using an angle with an R postfix that took radians though. So images could have a

Code: [Select]

RotateR(float radians);
function