| Forum Index > Tech Support |
|
kzn
United States1218 Posts
In the SC2 options (and, indeed, in the options of other games) there is a checkbox to enable "Reduce Mouse Lag", which warns that enabling it may drastically reduce FPS. My question is, what, precisely, does it do? Does it actually reduce mouse lag, or does it merely make it appear to lag less? | ||
|
SultanVinegar
United States372 Posts
| ||
|
semantics
10040 Posts
| ||
|
ionlyplayPROtoss
Canada573 Posts
| ||
|
InfiniteIce
United States794 Posts
| ||
|
Kaleido
6 Posts
 | ||
|
Ianuus
Australia349 Posts
| ||
|
ramen247
United States1256 Posts
On August 04 2010 08:54 Ianuus wrote: I'm having problems with lag while issuing shift commands on higher graphics settings. Will this option fix it? try it? what are your fps while playing on those settings? | ||
|
DevoKe
United States23 Posts
My fps didn't drop btw which I thought it would. It might be different for others but this is what I've experienced. | ||
|
TriniMasta
United States1323 Posts
| ||
|
Genome852
United States979 Posts
Does anyone know what 'reduce mouse lag' actually DOES? Besides stating the obvious, I'm curious as to how it actually... reduces mouse lag. At first I thought it would increase your mouse's polling rate so it had less delay - it makes sense since higher polling rate means more stress on the CPU, so your framerate would be reduced... but all mice have different usable polling rates and I don't think something like that would be in the game's options. Is it anything like "reduce input lag" for those that play WoW? It has almost exactly the same tool tip as this option in SC2. | ||
|
fdsdfg
United States1251 Posts
Since it cannot disable window's reading of the hardware input (only lock the pointer), this means the data is being read twice - by windows and by sc2. Now, instead of SC2 asking windows 'what's my x-y coordinates?' it has to have a hook into the mouse driver to read the raw input, interpret that into relative movements, and finally into x-y coordinates. Pro - not waiting on Windows API / polling rate Con - extra overhead | ||
|
cerb
Germany215 Posts
Well, nevertheless I have some questions: - Is it really true that most people play with it on? - Is there a special reason, why this effect is on some computers bigger than on others? | ||
|
ktang
United States196 Posts
| ||
|
harDmug
United Kingdom116 Posts
| ||
|
nvrs
Greece481 Posts
Seriously, i have an i7 oced to 3.5 Ghz and a 470GTX oced as well. At 1920x1080 @ 120 Hz i get 200 fps with gfx settings on low to medium (custom low mode) and reduce mouse lag off and 90 fps with it on and that's on the start of the game. With settings to Ultra i get 100 fps with it off and 60 with it on... | ||
|
diminish
2 Posts
On December 08 2010 06:49 fdsdfg wrote: 'Reduce mouse delay' will read the hardware input of the mouse rather than the Windows API. Since it cannot disable window's reading of the hardware input (only lock the pointer), this means the data is being read twice - by windows and by sc2. Now, instead of SC2 asking windows 'what's my x-y coordinates?' it has to have a hook into the mouse driver to read the raw input, interpret that into relative movements, and finally into x-y coordinates. Pro - not waiting on Windows API / polling rate Con - extra overhead From where have you pulled this out? On August 04 2010 07:50 semantics wrote: I just assume it lowers the rendered frames buffer or something like that. It's actually right and it can be easily observed - more stuttering when loading assets (initial larva inject animation stutter comes to my mind at first), also visibly less input lag, mouse input or not. | ||
|
ziteNiA
Sweden73 Posts
| ||
|
Ollwee
Sweden3 Posts
The Reduce Mouse Lag box? | ||
|
Rollin
Australia1552 Posts
On December 08 2010 06:49 fdsdfg wrote: 'Reduce mouse delay' will read the hardware input of the mouse rather than the Windows API. Since it cannot disable window's reading of the hardware input (only lock the pointer), this means the data is being read twice - by windows and by sc2. Now, instead of SC2 asking windows 'what's my x-y coordinates?' it has to have a hook into the mouse driver to read the raw input, interpret that into relative movements, and finally into x-y coordinates. Pro - not waiting on Windows API / polling rate Con - extra overhead This is generally called "Raw Mouse Input", so I would assume it is the max frame render buffer as others have said. I never bothered checking it out tbh (til now, I'll give it a try), but everyone's mileage will vary with this setting, so try it out for yourself and see if you have a preference, as opposed to wondering if others use it. To clarify further, my hypothesis is that it affects the maximum frames that can be rendered by the gpu before waiting for the cpu rendered frames, and if you are running at 60fps, changing this from (arbitrarily) 4 to 1 could decrease the noticeable "lag" input of the mouse (and equally keyboard, but it is much much harder to detect), from 4/60 ~ 67ms input delay to 1/60 ~ 16ms delay. Keep in mind a delay of 16 ms is the ABSOLUTE minimum possible with a 60 hz monitor, in reality it is likely to be larger, and again, one of the advantages of a 120 Hz monitor (which would allow for a theoretical 8ms minimum), for those that walk among us with superhuman skillz. | ||
| ||
|
|
CranKy Ducklings
Afreeca Starleague
Light vs Flash
INu's Battles
ByuN vs herO
PiGosaur Cup
Replay Cast
Replay Cast
The PondCast
OSC
Replay Cast
RSL Revival
[ Show More ] |
|
|
EPT
