Radian - Degree - Conversion

Introduction    

When we are talking about the value of angles most of us are used to think in degree.

In common language the phrase "to do a 180" just sounds better than "to do a 3.141592 radian" or even "to do a PI".

   

But game-engines, due to their unavoidable background in geometry, are somewhat different.

They use radian instead and that is the standard for almost all areas of mathematics.

   

What are radians?    

According to Wikipedia, "radian is the ratio between the length of an arc and its radius".

   

The meaning of this is that on a circle where the radius is 1 unit (the Unit Circle), the angle in radian IS the length of the arc.

The following diagram illustrates this thought.

   

    

Pic 1: This picture illustrates the connection between radian and degree. The length of the arc is the angle in radian.

   

One full turn please    

As we all learned at school in times past, the circumference (c) of a circle is ...

   

    

   

So the circumference of a circle with the radius r = 1 (the Unit Circle) would be...

   

    

   

   

    

Pic 2: This diagram illustrates the connection of the circumference of the Unit Circle and 2*PI.

Pretend that the circle unrolls the red line while rolling in the direction of the orange arrow. The purple angle-value has the unit degree (°) the red one's is radian (rad).

   

A little help converting    

Now everybody knows that two PI are 360 degree but in my experience the debugging of such values can be difficult.

So either you calculate the degree-value on the fly within the code or the debug-environment, or you could use the following handy table, that, in most cases, suffices.

   

  

Pic 3: We used a 8-direction compass that displays "east" for 0 degree rotation.

   

For all of you still searching for the right conversion-methods to use within your code:

   

(Angle in degree) = (Angle in radian) * PI / 180

(Angle in radian) = (Angle in degree) * 180 / PI

   

Clamping / Constraining    

In some cases, like when memorizing the rotation within a sprite-class it may be suitable to clamp the value according to its domain since there is no point in memorizing the number of turns in a single direction that brought you to this specific rotation and there always is the problem of a possible value-overflow of a variable.

   

You don't want to use the method "Clamp" in the XNA-MathHelper - Class because it returns the max-value if the upper boundary is exceeded (and the min-value vice versa).

   

All is good as long as you set the bounds for your valid angle to [-π, +π] as you will get the following output for the calculation: value % MathHelper.Pi

    

Pic 4: This output shows that a simple modulo-Pi - Calculation is sufficient if you want to constrain your angle to [-π, +π].

   

Nevertheless most programmers want the angle to be between zero and 2π, just like this:

    

Pic 5: The angle constrained to [0, +2π].

   

Here are two of our methods that we are actually using in production-code.

    

Pic 6: The first method constrains to a value within -Pi and +Pi by using a simple modulo-operation. The second one does a modulo-operation and always returns a positive value. This takes into account that a quarter-twist in the negative direction is the same as a three-quarter-twist into the positive one.

   

There are better methods out there using only one modulo-operation instead of two, which is pretty expensive, but we have not yet reached the performance-limits using this one and you know what they say.

Don't solve performance issues that have not yet occurred.

   

References    

• Wikipedia: http://en.wikipedia.org/wiki/Radian

Hello there!

Early in April 2011 my brother and I sat in the garden of our parents talking. Something we don't do often enough in our busy lives. We talked about doing a project together and with our last joint project lying back almost 20 years, we both thought that it's high time to do so again.

 

The first thing we had to do, after coming up with a workable idea for the game, was to choose the technology we wanted to use. The winner was C#, since it has been the language I used the most that time, and XNA, which I was completely inexperienced in.

All of that lies in the past now and we have quite something to show, but getting there really hasn't been easy at all and cost quite some time.

And that is the main reason we wanted to start this blog. We wanted to help inexperienced programmers to overcome the hazards of a new flavor of language and game programming in general, which, in my opinion, is nothing like ordinary programming at all.

 

So if you're on the search for someone to explain to you a thing or two about that stuff, then you're welcome to try here (but be warned: We don't know anything).

We generally don't offer code to download because we think that's a shortcut you shouldn't take. In some articles we'll link other websites that offer some code but you should try to understand the implications of the code that'll enable you to do the work yourself and frankly, sooner or later in the game development process, you won't be spared to do so.

We'll try to write the articles presented here in a way which should be both easy to understand and complete.

 

Feel free to comment anywhere on this blog if you have suggestions for topics to cover, found some mistakes or just have advice for improvement.

 

Who are we?

Wyzau is a pretty gifted provider of creative content, who has already done one or two minor games in Flash and doesn't fear a challenge and I'm a tolerable senior programmer who always has been fascinated by game development.

 

License

All the code and art within this blog, if not stated otherwise, is published by us using the MS-PL license.