1
2
Jan 31 2013, 6:59 pm
|
|
The code's pretty much the same, yours is more compact though. I'm crap with formatting.
|
It's probably because BYOND uses a truncated version of Pi.
Magnun2k's is pretty much the same, but highers factors of Pi. His is more accurate, but a bit slower as a result. Or at least that's what it seems to be. I'm gonna be updating the library soon to include get_angle_nums() which is the same as get_angle() but you can use four numeric values instead of atoms, in case you prefer that. Ultimately I'll cut the proc down to be universal and take any kind of entry. Ex: (num,num,atom)/(atom,num,num)/(atom,atom)/(num,num,num,num) But I'm lazy so that'll come later XD |
Actually, I made a mistake. Forget the 180 / PI since Lummox's atan2() returns an angle in degrees.
|
Also I think mine would be a bit faster without the call for round() and the checks to make sure the returned angle is between 0 and 360.
I figured I'd include that stuff for the sake or convenience. |
Give a few examples of what they return. It could be the same angle but in a different format..
Ex: 345 degrees = -15 degrees |
Another re-vamped version.
proc |
Ok, I got some more implementations, and all of them are returning the same values (I prefer North to be 0, South to be 180, East to be 90, and West to be 270).
Here's code and results: proc |
Ok, I got some more implementations, and all of them are returning the same values (I prefer North to be 0, South to be 180, East to be 90, and West to be 270). Unfortunately BYOND and trigonometry doesn't like that. You'll be making a -270 adjustment to every input. *shrugs* If that's how you prefer it though... |
In response to Bravo1
|
|
Bravo1 wrote:
Ok, I got some more implementations, and all of them are returning the same values (I prefer North to be 0, South to be 180, East to be 90, and West to be 270). Yeah, which isn't a big deal. |
1
2