Mnisape said:
fps = (1000 / milliseconds) / 1000
I had to reduce this and got: fps = 1 / milliseconds
Which is wrong, it should be: fps = 1000 / milliseconds
So maybe, because you still get seemingly correct results of 60fps, your time unit is not milliseconds but seconds.
Which might cause some confusion, so just mentioning that.
About your actual question, there are some issues which make it hard for you:
You want to integrate time. So work with time (measured realtime), not with the reciprocal of it (fps). Fps is rarely useful in general.
Because you integrate time, which is a real number, use real numbers, not integers. It provides the necessary precision to do integration, and avoids the costly conversation from float to int as well.
That said, i do not exactly understand what you try to do, but i assume you want some rotation at constant speed, not matter what's the actual fps.
This could work for example like so:
int64_t prevTimestamp = GetTime(); // function might return nanoseconds since computer was turned on, or seconds since some day in the 70's, or something like that
float objectAngle = 0;
float angularVelocity = 5; // angles per second
while (true)
{
int64_t curTimestamp = GetTime();
float deltaTime = ConvertDifferenceToSeconds(curTimestamp - prevTimestamp); // calculate seconds since the last iteration of our loop
prevTimestamp = curTimestamp;
objectAngle += angularVelocity * deltaTime;
DisplaySomeObjectAtAngle(objectAngle);
SwapImagesAndAllThatRenderingCrap();
}
With your approach you try something different:
while (true)
{
objectAngle += some constant like one degree;
Render();
Try to make the system pause for a given constant time, like 16 millisenonds to get 60 fps
}
Your mistake likely is the short delay of 1 (milliseconds?). That's not enough.
And likely your render framerate is capped to 60 fps by enabling vsync anyway.
So it already waits for 16 milliseconds anyway, and likely this wait factors in your given delay of one millisecond, so there is no observable effect in the end.
Assuming you're making it work as expected anyway, your approach may break e.g. if user changes a setting affecting vsync.
Or, your game becomes too slow to hit 60fps in some sections. Again your assumption of a constant timestep per frame would break, causing the game to feel wrong and not synced to realtime.
That's why it's actually better to (additionally) care about this time synchronization no matter if vsync is on or off.
But my code is just a basic example.
Usually you want to have constant timesteps for your physics updates, which brings us to the things discussed in the famous ‘fix your timestep’ article.
Google for it. But unfortunately it needs walls of text for what should be actually explained with 10 sentences at most. Still worth to read.