pythonarcade
Sprite: Consider storing the angle in radians
The internal _angle property should ideally be stored in randians. This can be done without breaking existing code. It means we can remove many conversions between angles and radians in various methods including the shader.
I thought about that. I thought the current setup was faster. If a game increases or manipulates the angles, it is done directly in degrees and doesn't have to be converted from radians to degrees, have math done, then back to radians. Plus it off-loads the conversion to the GPU.
Yep. We need to look into that. For simple use cases it's probably a tiny bit faster, but once you start doing something more with this angle we need to constantly convert it to radians. For example rotating the hit box points:
https://github.com/pythonarcade/arcade/blob/876805aab1d79c5e2b8f52df54f060852027ed58/arcade/geometry_generic.py#L36-L41
There are probably other examples of this. SpatialHash for example. Also combined with #1179 it can start to make more sense.
Some basic profiling is needed here.
Yep. We need to look into that. For simple use cases it's probably a tiny bit faster, but once you start doing something more with this angle we need to constantly convert it to radians. For example rotating the hit box points:
https://github.com/pythonarcade/arcade/blob/876805aab1d79c5e2b8f52df54f060852027ed58/arcade/geometry_generic.py#L36-L41
There are probably other examples of this. SpatialHash for example. Also combined with #1179 it can start to make more sense.
Some basic profiling is needed here.
@einarf Put that in a mixin?
There are too many other things relying on the angle being in degrees. I don't think this can be easily solved by mixins or other generic solutuon. The stored angle in the sprite just needs to be stored in either radians or degrees internally in the sprite.
We already have a raidans getter and setter. It converts the value to degrees when setting it, but we'll have to live with that for now.