Durante wrote: Took a while, but here I am
Now seriously, I was just reading this thread (since a friend asked me about the exact differences between G-sync with V-sync on/off in specific frame ranges, and jorimt's set of articles is the best resource I know on the subject), and I found the discussion of frame limiting latency impact that came up around the post I quoted (in June) very interesting.
I had some ideas about "predictive" external FPS capping a few years back: http://blog.metaclassofnil.com/?p=715
It never actually really worked out in my implementation, probably primarily since I didn't have any way to track the true V-sync timing at that point, and also because my implementation methodology was off. I do still think that the overall idea is viable, however. Of course, with most modern games you might well be halting the wrong thread this way.
RealNC wrote:Welcome back
What we haven't seen yet from anyone out there, is a "throttling" limiter. Meaning, do frame limiting even when not needed by always applying a few ms of wait time. In theory this should be easy to add to an existing limiter:
This should (I'm 99.99% certain) reduce input lag to the lowest possible value that any external, non-predictive limiter can possibly achieve.Code: Select all
if (frame_time < target_frame_time) { // Apply limit just like we always did. } else { // Apply a small limit here, sacrificing 1-2FPS, while previously this was a no-op. }
No one has done this yet, even though it does look like it's a dead-simple modification to any frame limiter :-/
masterotaku wrote:What about SpecialK for fps limiting?: https://github.com/Kaldaien/SpecialK/releases
It has an optional busy-wait limiter, framerate variance tolerance, and lots of features. And it has a GUI where you can change the settings in real time.
I tried it in Trails of Cold Steel and it's very smooth, but hammers one of my cores so much that it reaches >90 degrees, lol. Si I have that disabled, but keep the mod for custom textures.
RealNC's idea seems like the most straightforward way of ensuring lowest latency at all times with existing external framerate limiters, such as RTSS.Sparky wrote:I had some ideas about this. Obviously there's backpressure, but how hard would it be to modify the IO library to block the main game thread or render thread when it tries to gather mouse input, and use that block for rate limiting? Obviously this won't work for all games, as multiple threads might be reading input, but for at least a few games it should give you the lowest possible latency.
@RealNC, I assume you mean setting a framerate target once for the given game, but instead of applying as a static number (e.g. 142 FPS at 144Hz), it would apply as an offset (e.g. -1 FPS, -2 FPS, etc) to the current framerate. This means if the output framerate is 110 frames, it would limit to 108, 39 to 37 limit, and so forth.
While this wouldn't be as low latency as an in-game limiter, it would prevent pre-rendered frames from kicking in and reduce latency at all framerates (instead of just at a single set limit), since the limiter would become the framerate's limiting factor in all instances.
@masterotaku, I've never used SpecialK. Are you saying it does something similar to the above, but is too hard on the CPU as a result?
