There are numerous ways of smoothening a rotation. If there is any physical meaning to it, we'll need to know what that is, but if you are merely doing it to make it appear less jerky, it is pretty arbitrary. Note that unless you know what the velocity is going to do in advance, any attempt to smoothen the corresponding rotation will cause it to lag behind to some degree, which may lead to weird oscillatory behaviour. It also prevents you from smoothly setting the rotation to zero simultaneously with the velocity hitting zero.
A simple way would be to make the rotation respond exponentially, i.e. use an angular velocity proportional to the difference between the sprite's current and target rotation.
targetrotation = fmaxf(fminf(playerVelocity.x * Proportion, maxDiff), -maxDiff);
angularvelocity = (targetrotation - player.rotation) * rotationspeed;
player.rotation += angularvelocity * timestep;
Let's say your
playerVelocity.x looked like this:
The plots below indicate an example rotation against time using various values for
rotationspeed using this exponential smoothening method.
You may want to cap the angular velocity to zero under a specified magnitude. The integration method is very crude and given enough time to settle, the timestep will eventually be too large and the rotation will overshoot its target. The resulting oscillation might even consistently increase in amplitude. An example:
Imagine the rotation being very close to its target. As it comes closer, the angular velocity should gradually decrease until it eventually stops. However, the angular velocity isn't constantly updated; it is updated once every timestep. During these steps, the angular velocity should be decreasing, but instead, the rotations keeps changing at a constant rate. Below is what might happen.
The yellow line indicates the intended behaviour. You can see the blue line (timesteps of 0.1) starts with the right slope, but isn't updated for a while. It's a little high, but doesn't cause any major issues. The red line has more time in between steps (0.2). By the time the slope is updated, the rotation has overshot its target.
There are more elaborate ways of tackling this problem, but you are somewhat handicapped by the fact that the target rotation might be changing too. The simplest way would be to specify a range around the target where the rotation is 'close enough' and should stop moving. How large this range should be depends on your timestep and maximum angular velocity, but I suggest some experimentation.