From Transformable.cpp:
////////////////////////////////////////////////////////////
const Transform& Transformable::getTransform() const
{
// Recompute the combined transform if needed
if (m_transformNeedUpdate)
{
float angle = -m_rotation * 3.141592654f / 180.f;
float cosine = static_cast<float>(std::cos(angle));
float sine = static_cast<float>(std::sin(angle));
float sxc = m_scale.x * cosine;
float syc = m_scale.y * cosine;
float sxs = m_scale.x * sine;
float sys = m_scale.y * sine;
float tx = -m_origin.x * sxc - m_origin.y * sys + m_position.x;
float ty = m_origin.x * sxs - m_origin.y * syc + m_position.y;
m_transform = Transform( sxc, sys, tx,
-sxs, syc, ty,
0.f, 0.f, 1.f);
m_transformNeedUpdate = false;
}
return m_transform;
}
So obviously Laurent accepts degrees, converts them to radians to generate the transformation matrix and feeds that to OpenGL via glLoadMatrix.
he doesn't use any OpenGL function that takes angles
He does the matrix maths himself instead of let OpenGL do it for him.
Yah the only function that takes degrees in OpenGL is glRotatef and that's been deprecated since OpenGL 3.0+ and removed since 3.1+.
Just like almost every other function Laurent uses in SFML... Laurent has other things to worry about than self-imposed deprecation restrictions. He already said OpenGL ES support was a goal, but until then, you just have to live with the fact that SFML runs on deprecated OpenGL code.
In either case there is conversions but I find it is obvious which case would require less conversions and is more efficient than the other cases.
You really shouldn't worry about angle conversions. It is a pure mult/div in hardware. It can be done in very few clock cycles if indeed more than a single one. This is not even nearly comparable to other things in your code.
