Cap FPS internally or externally?
Cap FPS internally or externally?
Which is the better option with G-Sync? Capping FPS in-game (I.e. fps_max) or with an external program like dxtory? Or in the GPU options?
Re: Cap FPS internally or externally?
In-game is always the best.dmbr wrote:Which is the better option with G-Sync? Capping FPS in-game (I.e. fps_max) or with an external program like dxtory? Or in the GPU options?
Re: Cap FPS internally or externally?
Well, no... with gsync it doesnt matter....
You might as well cap it globally with rivatuner statistics server, just cuz its easier
You might as well cap it globally with rivatuner statistics server, just cuz its easier
Re: Cap FPS internally or externally?
Capping framerate anywhere but in game adds input latency. The further down the pipeline you cap framerate, the more input latency you add.Edmond wrote:Well, no... with gsync it doesnt matter....
You might as well cap it globally with rivatuner statistics server, just cuz its easier
Re: Cap FPS internally or externally?
Yep. If you cap in-game the game will wait a little bit and grab newer input then send it off to be rendered. If you cap at the driver level the game will grab input right away then send it off.Sparky wrote:Capping framerate anywhere but in game adds input latency. The further down the pipeline you cap framerate, the more input latency you add.Edmond wrote:Well, no... with gsync it doesnt matter....
You might as well cap it globally with rivatuner statistics server, just cuz its easier
-
- Posts: 505
- Joined: 18 Dec 2013, 23:51
Re: Cap FPS internally or externally?
If you cap ingame framerate to 10 fps, surely that adds a great deal of input lag no? (at least as measured as the time between doing something, like moving the mouse, and seeing it occur on screen)Sparky wrote:Edmond wrote: Capping framerate anywhere but in game adds input latency. The further down the pipeline you cap framerate, the more input latency you add.
Re: Cap FPS internally or externally?
That makes external capping sound superior?sharknice wrote:Yep. If you cap in-game the game will wait a little bit and grab newer input then send it off to be rendered. If you cap at the driver level the game will grab input right away then send it off.Sparky wrote:Capping framerate anywhere but in game adds input latency. The further down the pipeline you cap framerate, the more input latency you add.Edmond wrote:Well, no... with gsync it doesnt matter....
You might as well cap it globally with rivatuner statistics server, just cuz its easier
Re: Cap FPS internally or externally?
Yes and no, depending on what you're measuring. When a frame finishes, it includes all input data older than X milliseconds. When the user makes an input it takes Y milliseconds to see a new frame that incorporates that input.spacediver wrote:If you cap ingame framerate to 10 fps, surely that adds a great deal of input lag no? (at least as measured as the time between doing something, like moving the mouse, and seeing it occur on screen)Sparky wrote:Edmond wrote: Capping framerate anywhere but in game adds input latency. The further down the pipeline you cap framerate, the more input latency you add.
If you are CPU limited already, an in-game framerate cap will leave X untouched, and increase Y.
If you are GPU or display limited, an in-game framerate cap will decrease X, and can decrease Y, depending how much the cap decreases your framerate, and how much queue latency you started with.
GPU framerate caps will only decrease latency if the alternative is v-sync.
-
- Posts: 505
- Joined: 18 Dec 2013, 23:51
Re: Cap FPS internally or externally?
I *think* I'm starting to understand.
So there is:
1) the delay between input and that input being reflected in a (buffered) frame.
2) the delay between the creation of that buffered frame, and that frame being drawn on the screen.
Now what about the server or game world simulation (dunno what the correct term is here)? Let's say it takes 100 ms for a button press to be reflected in the next available buffered frame, and another 100 ms for that frame to be displayed on my screen. In the gameworld, when does that button press occur? Is it T+100ms (where T is moment of button press)?
So there is:
1) the delay between input and that input being reflected in a (buffered) frame.
2) the delay between the creation of that buffered frame, and that frame being drawn on the screen.
Now what about the server or game world simulation (dunno what the correct term is here)? Let's say it takes 100 ms for a button press to be reflected in the next available buffered frame, and another 100 ms for that frame to be displayed on my screen. In the gameworld, when does that button press occur? Is it T+100ms (where T is moment of button press)?