flood wrote:I believe the only case where it would affect anything would be a game that forces a constant fps using a loop with Sleep
Sleep() uses whole milliseconds. So I don't think it would have much of an effect.
Busy wait loops on multimedia timers without sleeps, would be far more accurate. More power consuming, but for delays under 1ms, in certain cases it may
actually lead to reduced stutters depending on how the frametime logic works, due to more consistent frame times at 0.5ms granularity. But most engines do not depend on this for frametimes during internal game-engine frame rate capping.
1ms random fluctuations in frame times means sudden jumps from 144fps (7ms) to 125fps (8ms) to 111fps (9ms) to 100fps (10ms). THIS
is where better-than-0.5ms granularity is frequently needed, not for input lag, so sleeps are not usually used to wait for the next frame time. In theory, 0.5ms timer ticks could make accurate usleep() easier for the operating system to do power management at 0.5ms intervals (microsecond sleeping) since otherwise possibly energy-hogging busy wait loops are needed for accurate sub-1ms waits. On the other hand, the overhead of the higher frequency may outweigh this. All a matter more important for mobile devices.TL;DR: it is not going to appreciably affect input lag in typical games, but one odd game may suddenly have fewer stutters if its frametime logic depends on this timer.