libsdl-org
SDL_RenderTextureRotated should accept angle in different notations
Currently this function only accepts angle in degrees, however most applications already have angles in radians. Also, box2d 3.0 returns rotation as a pair of sine and cosine. So SDL3 could improve performance if SDL_RenderTextureRotated also accepted a pair of sine and cosine. For this purpose, two helper functions should be added that will build such a structure from degrees and radians.
struct SDL_Rotation {
float sine;
float cosine;
};
SDL_Rotation SDL_GetRotationFromRadians(double radians);
SDL_Rotation SDL_GetRotationFromDegrees(double degrees);
In case of box2d 3.0 we can use pre-calculated value.
Want to say no here, unless @slouken feels strongly about it.
Getting degrees from radians is just:
degrees = radians * (180.0f / SDL_PI_F);
Want to say no here, unless @slouken feels strongly about it.
Getting degrees from radians is just:
degrees = radians * (180.0f / SDL_PI_F);
When I use box2d, I have a cosine and a sine. So, I need to call atan2 to get radians, and then I need to convert them to degrees. But SDL will perform the reverse operations and calculate radians from degrees, and then sine and cosine. It looks like an overhead.
@brainstream Trying to warp SDL to bend around box2d's limitations doesn't seem like a good solution. I ended up making my own angle system, which ends up passing an angle to SDL as: angle / ANGLE_DIVISOR. Angle overhead is something you can solve outside of SDL.
That's an interesting optimization. We do convert the angle to sin/cos in every path that handles rotation. We're not going to change the API for the 3.2.0 release, but we can consider this in the future.
That's an interesting optimization. We do convert the angle to sin/cos in every path that handles rotation. We're not going to change the API for the 3.2.0 release, but we can consider this in the future.
I’m curious to know what you think of the affine interface proposed above as a solution to this optimization use case?
I dig it.