Timeline for Why are radians preferred over degrees in game development?
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 24, 2013 at 18:15 | comment | added | ddyer | Of course the actual rotation requires irrational numbers, but tracking the desired angle of rotation should be done with some form of rational which is free of rounding errors. Claiming "it shouldn't be much of a problem" is the first hand-wave on the way to a disaster. | |
| Dec 24, 2013 at 10:59 | comment | added | Marcks Thomas | An angle of 1 degree may be easier to represent accurately in degrees than in radians, rotating an object isn't exact either way, as it requires trigonometrical functions. cos 1° is as much subject to rounding errors as pi/180. | |
| Dec 24, 2013 at 3:34 | comment | added | Michael Stum | @DMGregory That was what I meant with "inherent rounding error with Pi". The other option is to not use singles/doubles but a way to represent numbers as factors (so representing 2*pi/360 not as the result of the calculation but as that formula) and only calculate the result when needed. I don't know if any "real" programs do that, but stuff like Mathematica can always represent "1/3" as "1/3" instead of "0.333333.....". But after going through the numbers I guess you're right, the rounding error is there but insignificant | |
| Dec 23, 2013 at 23:47 | comment | added | DMGregory♦ | See the "millions of pixels" note above. For sprites of typical sizes (say, on the order of 2048 pixels wide, or smaller) the error will be substantially less than half a pixel, and so will be erased by the inherent rounding of the pixel grid itself. Also, note that rotating 360/7 degrees at a time will accumulate the very same errors. You can eliminate rounding errors with both systems by sticking to increments that are representable as a sum of powers of two (with some limit on the exponent range), but it's probably easier to change to code that doesn't accumulate many small increments. | |
| Dec 23, 2013 at 23:05 | comment | added | ddyer | From a numerical perspective you're correct, but from a visual perspective if ONE pixel from a hard edge pops to the wrong value, you're screwed. | |
| Dec 23, 2013 at 20:15 | comment | added | DMGregory♦ | Testing this empirically, after four 90-degree rotations with a single precision float increment in radians, I find a total error of 1.75E-7 (less than 1 part in 5 million). On a pixel grid, the radius of the rotating object/frame would need to be in the millions of pixels before you would experience 1 pixel of error at the outer edge (a point more than 0.5 linear px from where it should be). In other words, precision loss is unlikely to be an issue in practice (especially if you use doubles). | |
| Dec 23, 2013 at 18:54 | history | answered | ddyer | CC BY-SA 3.0 |