Radian helper functions

[workmad3]

I mentioned this in another thread, but I'll put it here as well.

Helper functions/function overloads for when a transformation uses angles in degrees that would accept a radian argument instead and do the conversion would be a nice feature.

I know it isn't difficult to write the helper functions separately, but it's an extra thing to remember, along with doing an extra function call or multiplication every time they are used. An overload (possibly with the postfix character R, so a Rotate(float degrees) method would also have a RotateR(float radians) variant) to do this with an inline class method would make the conversion simpler to remember, and make SFML more appealing as it doesn't enforce a particular convention upon library users regarding how they should use angles

[Laurent]

No no no... Really, I can't put 24 versions of each function just to match every possible convention / unit / whatever.

Degree - radian conversion is the simplest / cheapest thing to add on user side, why does everybody complain about it missing in SFML ? :|

PS : sorry I don't mean to be rude, I'd just like to understand why so many people focus on such a small thing rather than interesting improvements

[zarka]

becouse it's the small and simple things that are the easiest to have oppinions about

and here is all the radians degree conversion anyone will ever need

Code: [Select]


#define RAD_TO_DEG 180/PI
#define DEG_TO_RAD PI/180


[workmad3]

The little things matter, is the main thing

The other reason I suggest it is because it gets really annoying as a library user to always have to remember to write the conversions (or dig them out of an archive or old project every time I start a new project) and to use them. Libraries are meant to abstract away from the small and annoying tasks, and you can't get smaller or more annoying than having to either change all your formulae or remember conversion functions and essentially be considered a second-class user of the library because you want to use a more mathematically correct unit.

Not to mention with it being a small thing that a lot of people complain about, wouldn't it be easier to put in helper functions for the most common units (i.e. radians) than to be constantly barraged about their absence?

[Laurent]

One thing I'm also concerned with, is not bloating the public interface of the classes with many functions basically doing the same thing, whereas this thing can be done on user side with one line of code if you need it.

[jamba]

In 0x will you be able to define a suffix for literals to convert them? ie my_function(180degrees) or my_function(3.14radians). That would be great if you could, but maybe I'm just completely misunderstanding the proposals.  :lol

[kolofsson]

I posted this suggestion a few days ago, but now I have to agree with Laurent. You can store all angles as radians and you only use the conversion when setting the sprite.angle.

Other story is the angle direction because it has to be reverted every time you want to use it in classic trigonometrical functions (like calculating vector components). But again, I CAN live without it.

[workmad3]

Yeah, I read and commented on your original post and that was pretty much my inspiration for raising this.

[Avency]

Most compilers will be able to optimize this function call away (yeah, I hate preprocessor makros).
But I have to admit that I prefer radians myself.
Replacing degrees with radians would imho be a good solution.
So instead of Rotate(float degree), write Rotate(float radians). Thinking of cmath, etc. this is probably used more often.