smoother timing in frame limiter #1415
Conversation
|
This should fix some of the issues we were having with the framelimiter and sets it as the default. |
|
this has a math bug in the windows sleep |
| #define NOMINMAX | ||
| #include <Windows.h> | ||
|
|
||
| void sleep_us(u64 us) { |
There was a problem hiding this comment.
Why have two different implementations of sleep_us?
There was a problem hiding this comment.
One is for linux and the other is for Windows.
There was a problem hiding this comment.
Uh, yeah. I meant why not use
void sleep_us(u64 us) {
std::this_thread::sleep_for(std::chrono::microseconds(us))
}for both platforms?
There was a problem hiding this comment.
We need sleeps that are accurate to a few ms for this to work, but the default windows timer resolution is (sometimes) ~15 ms. that's almost a whole frame long, so it becomes impossible to sleep for the right amount of time. The solution is to use the windows API to request a higher timer resolution and do the sleeps manually.
The C++ standard library sleeps are kinda weird too, they have very poorly specified behavior:
"The standard recommends that a steady clock is used to measure the duration. If an implementation uses a system clock instead, the wait time may also be sensitive to clock adjustments."
and we definitely wouldn't want the frame limiter to be affected by somebody changing their system time...
There was a problem hiding this comment.
Makes sense. I did not realise that the std sleeps were so poorly defined. I always assumed they were a steady clock, because as you said, if they're not that's hugely problematic.
No description provided.