Most game engines work in radians under the hood and expose degrees in the UI but still need to glue the UI values to the API which is the code seen in Casey’s Godot example the full context of which is a color picker and h has already been converted from degrees. Godot itself has a bunch of the API in degrees which is pretty bleugh.
It's for convenience of developing tooling. Because the only thing harder than re-framing all of mathematics so that sine and cosine are properly defined in terms of turns would be teaching artists and level designers to believe that a full turn is 2π radians instead of 360 degrees.
Yeah tooling is fine in degrees, which is what I was saying in the first part off my post. It’s more mixing it in the API rather than at the boundaries that is bleugh.
Most APIs are intended to be used, doesn’t mean you need to mix units, particularly when they both use the same basic type and thus are easy to muddle up. That’s why you keep the API consistent and deal with conversion at the edges. I get you’re probably very keen on Godot but it’s definitely one of the weird warts that all engines accumulate and my intention isn’t to say it’s bad because of this choice. Just that I don’t like that choice and the reason why.
Ah, I see what you mean. I tend to be operating with APIs in languages that wouldn't call radians and degrees the same units and wouldn't let you just call a function that takes radians with degrees without an explicit cast; forgot that was a thing people have to worry about.
That’d definitely be my preference as well. Games is full of this as well. Handedness and general definition of coordinate system is another fairly arbitrary decision you want to keep consistent in your API but have to translate at the boundaries quite often.
