[BUG] Framerate limiter always maintains 60 FPS for higher FPS targets

[beewyka819]

Describe the bug
On Windows, when enabling the frame limit at application.c:645, it will limit the framerate to approximately 60 FPS even when target_frame_seconds is smaller than 1.0f / 60. For example, when setting target_frame_seconds to 1.0f / 144, printing out 1.0f / delta, which should give the framerate (inverse of period), it will still yield approximately 60 FPS. Interestingly this does not occur for target_frame_seconds greather than 1.0f / 60 (i.e. 1.0f / 30), although the yielded FPS seems to be rather unstable. To be honest I'm having trouble figuring out exactly why this is occurring. The clock logic at least seems correct to me. I wonder if it's due to a technical detail with the Windows Sleep function.

To Reproduce
Steps to reproduce the behavior:

1. In application.c, switch limit_frames on line 645 to true.
2. Change target_frame_seconds to a different value (i.e. 1.0f / 144).
3. Log the frequency each frame (1.0f / delta).
4. Build and run the program and observe the logged frequency.

Expected behavior
When changing target_frame_seconds to 1.0f / X, then the FPS should attempt to maintain 'X' FPS while the limiter is enabled.

Desktop (please complete the following information):

• OS: Windows

[beewyka819]

Found a solution to this, it is related to the default accuracy of the windows Sleep function. This accuracy is normally tied to the interrupt ticks (64 per second), but can be adjusted manually with timeBeginPeriod(). Will create a PR that demonstrates the fix.