AMD/NVDIA by default have buffer set to 3 (3 frames), adding on a fourth with the NS2 engine can benefit that, ofcourse it should be 16-32ms but at the end of the day most people aren't noticing the input lag because they are already getting worse FPS.
NS2 forces this to 1 frame, so you are basically doubling that. Also, the lower fps you have the greater relative mouse lag increases. In that sense improved fps might compensate that. (if by great amount)
Gpu defaults 3
NS2 defaults (? doesn't touch gpu's 3 and doesn't apply its own)
gpu default + r_sync 1 = best combination by far
Touching r_sync in NS2 doesn't change the gpus Flip Queue/nvidia frame buffer, by default nor what you have infront of you, it only adds to it, so technically you're adding a fourth frame to be buffered when adding r_sync 1, which is why progressively you get more input delay/lag, actually if you touch flip queue and drop it down from 3-2 then apply r_sync 1 you lose 20fps, so leave it on 30, unless you want to have less input lag.
Nope, where'd you hear that? i mentioned that this command has been broken since about four patches before February 2014, if it was intended to force the gpu default to 1, it's failing, because ns2 default with gpu default = 100fps, and with ns2 default and gpu set to 1 it's 80fps hence why if the ns2 forces gpu default to 1, it's clearly not working since i'm losing 20fps simply by doing it manually, if anything the command doesn't do anything when it's set to r_sync 0, it just disables how ns2 interacts with the graphics card setting.
edit:i've just gone through this, by default ns2 doesn't enforce any r_sync whodacery, if you manually set r_sync to 1 it will stay at 1, but if you set it to 0 it will forget it at next restart, r_sync 0 (doesn't apply on start of game, so if it was intended to change the gpu's flip queue/maximum pre-rendered frames, then it isn't working, but if you change while in game, it changes it on the fly (and if set over 0 it'll remember through to the next time you restart)
edit2:rendering % goes up when i set r_sync 0 5-10ms vs no increase with r_sync 1, could that be the reason i don't notice, because what ever is added is minimal compared with what should be added, r_sync 0 is adding latency too by default for no reason?
Managed to get my rendertime down to 1ms here on pretty crap gpu with decent cpu.
Nope, where'd you hear that? i mentioned that this command has been broken since about four patches before February 2014, if it was intended to force the gpu default to 1, it's failing, because ns2 default with gpu default = 100fps, and with ns2 default and gpu set to 1 it's 80fps hence why if the ns2 forces gpu default to 1, it's clearly not working since i'm losing 20fps simply by doing it manually, if anything the command doesn't do anything when it's set to r_sync 0, it just disables how ns2 interacts with the graphics card setting.
edit:i've just gone through this, by default ns2 doesn't enforce any r_sync whodacery, if you manually set r_sync to 1 it will stay at 1, but if you set it to 0 it will forget it at next restart, r_sync 0 (doesn't apply on start of game, so if it was intended to change the gpu's flip queue/maximum pre-rendered frames, then it isn't working, but if you change while in game, it changes it on the fly (and if set over 0 it'll remember through to the next time you restart)
edit2:rendering % goes up when i set r_sync 0 5-10ms vs no increase with r_sync 1, could that be the reason i don't notice, because what ever is added is minimal compared with what should be added, r_sync 0 is adding latency too by default for no reason?
Managed to get my rendertime down to 1ms here on pretty crap gpu with decent cpu.
It was introduced at the time when max was minimising mouse lag. It might have been as early as before release or after that. I don't remember there being any note of changing that afterwards. Anyhow, I guess I wouldn't notice if it broke because I'm forcing it to 1 from drivers. I played with it during this summer though and didn't notice the difference so I was expecting it to still apply.
I would expect people generally to notice this as increased mouse lag if it was changed/broke but it's hard to tell at this point. There has been so many builds introducing stuff like that as well as fixing it.
edit. I got bit interested in that r_sync command. Did you find the default values empirically or read it somewhere? Wiki has basically no info of it.
Input lag at the core of things, it's only affecting the mouse. and 500hz, 1000hz polling rates (most gamers use is enough to bypass this including with other mouse fixes, whoever uses 125hz deserves to be shot in the foot tbh.
That is incorrect.
Input lag is not limited to the mouse, nor will polling rates "Bypass" any additional input lag induced through additional frame buffering.
Gpu defaults 3
NS2 defaults (? doesn't touch gpu's 3 and doesn't apply its own)
Again, you are posting inaccurate information.
NS2 actually overrides the D3D API, since it adds its own frame buffer by default on top of whatever is naturally occurring.
What Vartija said is true. This has been the case since before release, and then it broke after Reinforced and was again fixed a month later.
At this point, please cease posting in this thread, as you consistently posting misinformation and debating it is clogging up what otherwise might have been a helpful thread to the OP.
In other words, cease derailing, and if you wish to take up a discussion, do so in "General Discussion".
Back on topic, thanks to everyone. Downscaled the res to 1280x760. It runs like silk and it's not even that pixelated. The dramatic FPS drops still occur, but less frequently (guess this happens only on "hard" moments, like 3 onos wandering thought the Marines main base with exos fighting back, Lerks gasing and structures exploding. Quite scenic tho)
@ATF About Wooza's Playground, yes, ya busted mah, I'm there sometimes :P it was the first server I tried (Playground and Hamster Wheel) so I feel quite comfortable there. Will try the ones you suggested
matsoMaster of PatchesJoin Date: 2002-11-05Member: 7000Members, Forum Moderators, NS2 Developer, Constellation, NS2 Playtester, Squad Five Blue, Squad Five Silver, Squad Five Gold, Reinforced - Shadow, NS2 Community Developer
edited December 2014
What r_sync does is to force the game to wait until the number of buffered frames in the GPU is <= r_sync. So setting r_sync to 0 forces the game to wait until the GPU is done with all frames worth of data (bad for fps), while 1 waits until it has no more than 1 frame to process before starting to work on the next one.
This ensures that a slow GPU does not increase your input lag - it is also better than the card letting you have at most x frames (3 by default) worth of frame data buffered in the card before it blocks you when you try to send the next frame.
Default r_sync is 1, except possibly if you have some kinds of SLI configs - then it might be two.
NS2 works on three frames at the same time - the GPU works on displaying frame-2, the render thread renders frame-1 and the update thread updates the world data for frame-0 (where it handles your current input).
So if you look at how much difference there is between what is on the screen in front of you and what your input are applied to, there is a minimum of 3 frames worth of difference due to pipeline setup.
Now, considering that it takes your brain about 100ms to process the visual image, maybe another 100ms to process it and maybe another 50ms before the nerve signal manages to get your fingers to press the mouse button... those three frames adds maybe 15-50 ms to your input latency.
Fortunately for us, our brains actually runs our internal brain-generated world lag-compensated so we don't have to worry about eye-brain-finger latency.
IronHorseDeveloper, QA Manager, Technical Support & contributorJoin Date: 2010-05-08Member: 71669Members, Super Administrators, Forum Admins, Forum Moderators, NS2 Developer, NS2 Playtester, Squad Five Blue, Subnautica Playtester, Subnautica PT Lead, Pistachionauts
edited December 2014
I've twice asked him for that in PMs.
If that is indeed the case (and these users aren't just experiencing a false positive from trying r_sync 0 in comparison and believing the inaccurate Wiki defaults) I wonder how some users have outdated system_option files when most have updated ones.. Doesn't make sense how a file could have been updated in a patch and not apply to everyone. Unless they manually restored it later?
I wonder how some users have outdated system_option files when most have updated ones.. Doesn't make sense how a file could have been updated in a patch and not apply to everyone. Unless they manually restored it later?
Does update through Steam touch files outside library dirs?
Comments
NS2 forces this to 1 frame, so you are basically doubling that. Also, the lower fps you have the greater relative mouse lag increases. In that sense improved fps might compensate that. (if by great amount)
NS2 defaults (? doesn't touch gpu's 3 and doesn't apply its own)
gpu default + r_sync 1 = best combination by far
Touching r_sync in NS2 doesn't change the gpus Flip Queue/nvidia frame buffer, by default nor what you have infront of you, it only adds to it, so technically you're adding a fourth frame to be buffered when adding r_sync 1, which is why progressively you get more input delay/lag, actually if you touch flip queue and drop it down from 3-2 then apply r_sync 1 you lose 20fps, so leave it on 30, unless you want to have less input lag.
Nope, where'd you hear that? i mentioned that this command has been broken since about four patches before February 2014, if it was intended to force the gpu default to 1, it's failing, because ns2 default with gpu default = 100fps, and with ns2 default and gpu set to 1 it's 80fps hence why if the ns2 forces gpu default to 1, it's clearly not working since i'm losing 20fps simply by doing it manually, if anything the command doesn't do anything when it's set to r_sync 0, it just disables how ns2 interacts with the graphics card setting.
edit:i've just gone through this, by default ns2 doesn't enforce any r_sync whodacery, if you manually set r_sync to 1 it will stay at 1, but if you set it to 0 it will forget it at next restart, r_sync 0 (doesn't apply on start of game, so if it was intended to change the gpu's flip queue/maximum pre-rendered frames, then it isn't working, but if you change while in game, it changes it on the fly (and if set over 0 it'll remember through to the next time you restart)
edit2:rendering % goes up when i set r_sync 0 5-10ms vs no increase with r_sync 1, could that be the reason i don't notice, because what ever is added is minimal compared with what should be added, r_sync 0 is adding latency too by default for no reason?
Managed to get my rendertime down to 1ms here on pretty crap gpu with decent cpu.
It was introduced at the time when max was minimising mouse lag. It might have been as early as before release or after that. I don't remember there being any note of changing that afterwards. Anyhow, I guess I wouldn't notice if it broke because I'm forcing it to 1 from drivers. I played with it during this summer though and didn't notice the difference so I was expecting it to still apply.
I would expect people generally to notice this as increased mouse lag if it was changed/broke but it's hard to tell at this point. There has been so many builds introducing stuff like that as well as fixing it.
edit. I got bit interested in that r_sync command. Did you find the default values empirically or read it somewhere? Wiki has basically no info of it.
Input lag is not limited to the mouse, nor will polling rates "Bypass" any additional input lag induced through additional frame buffering.
Again, you are posting inaccurate information.
NS2 actually overrides the D3D API, since it adds its own frame buffer by default on top of whatever is naturally occurring.
What Vartija said is true. This has been the case since before release, and then it broke after Reinforced and was again fixed a month later.
At this point, please cease posting in this thread, as you consistently posting misinformation and debating it is clogging up what otherwise might have been a helpful thread to the OP.
In other words, cease derailing, and if you wish to take up a discussion, do so in "General Discussion".
Back on topic, thanks to everyone. Downscaled the res to 1280x760. It runs like silk and it's not even that pixelated. The dramatic FPS drops still occur, but less frequently (guess this happens only on "hard" moments, like 3 onos wandering thought the Marines main base with exos fighting back, Lerks gasing and structures exploding. Quite scenic tho)
@ATF About Wooza's Playground, yes, ya busted mah, I'm there sometimes :P it was the first server I tried (Playground and Hamster Wheel) so I feel quite comfortable there. Will try the ones you suggested
This ensures that a slow GPU does not increase your input lag - it is also better than the card letting you have at most x frames (3 by default) worth of frame data buffered in the card before it blocks you when you try to send the next frame.
Default r_sync is 1, except possibly if you have some kinds of SLI configs - then it might be two.
NS2 works on three frames at the same time - the GPU works on displaying frame-2, the render thread renders frame-1 and the update thread updates the world data for frame-0 (where it handles your current input).
So if you look at how much difference there is between what is on the screen in front of you and what your input are applied to, there is a minimum of 3 frames worth of difference due to pipeline setup.
Now, considering that it takes your brain about 100ms to process the visual image, maybe another 100ms to process it and maybe another 50ms before the nerve signal manages to get your fingers to press the mouse button... those three frames adds maybe 15-50 ms to your input latency.
Fortunately for us, our brains actually runs our internal brain-generated world lag-compensated so we don't have to worry about eye-brain-finger latency.
It might be that very ancient versions of ns2 set the value to 0 in the configuration file. Newer versions clearly do not.
I for example have no fps difference when setting r_sync to 1, but a 40% drop when setting to 0.
Could you post your ns2 configuration file in here? That would help
If that is indeed the case (and these users aren't just experiencing a false positive from trying r_sync 0 in comparison and believing the inaccurate Wiki defaults) I wonder how some users have outdated system_option files when most have updated ones.. Doesn't make sense how a file could have been updated in a patch and not apply to everyone. Unless they manually restored it later?
Does update through Steam touch files outside library dirs?