|
As of now, Overwatch only lets you set integer multipliers for your sensitivity in-game. This is highly inconvenient for those who wish for more fine-grained control of numerical sensitivity.
The solution? Use Povohat's Interaccel driver to set up a linear scaling ("Acceleration = 0" and "Power = 1"):
http://mouseaccel.blogspot.ca/2015/12/new-method-for-mouse-acceleration.html
This scaling works for Overwatch's rawinput because it uses the interception library.
_________________________________________________
As an example, here are my settings in CS:GO
sensitivity 2.28
m_yaw 0.022
zoom_sensitivity_ratio_mouse 1
At a resolution of 1920x1080 (horizontal FOV ~ 106.26 degrees),
We know that in Overwatch, the equivalent of m_yaw is 0.0066 degrees.
To get the equivalent rotational multiplication, this means that the sensitivity should be at 7.6 in Overwatch.
So we set the sensitivity to 8 in-game, and in Interaccel set acceleration to 0 and Post-Scale X/Y at 0.95 (use post-scale to minimize binary rounding).
I also have Widowmaker scope sensitivity at 50% to match zoom_sensitivity_ratio_mouse 1 in Source, since Widowmaker scope FOV is 51.5 degrees.
Note: if you are OCD about the "feel", there is actually a caveat for the above configuration.
The above setting makes for equivalent turn radius (i.e. cm/360), which is important for those who often do >FOV flicks. But, for the vast majority of players who lift their mice for adjustments, we perceive the sensitivity not by absolute turn radius, but rather by the proportion of the viewport being shifted.
Since Overwatch FOV is different from CS:GO, we should instead aim for equivalent FOV fraction.
Assuming a FOV of 103 in Overwatch, this means that our equivalent Overwatch sensitivity should be ~7.36, i.e. Interaccel multiplier of 0.92.
|
GRAND OLD AMERICA16375 Posts
doesn't this fuck with raw input or does overwatch not have that?
|
On June 23 2016 05:45 amazingxkcd wrote:
doesn't this fuck with raw input or does overwatch not have that?
The whole point is to intercept and scale the mouse input before it reaches Overwatch's rawinput. The Interaccel scaling is to compensate for OW's lack of decimal scaling steps.
|
United Kingdom20316 Posts
Wouldn't this make some sensor counts act as 0 or 2 counts rather than 1:1 and mess up the mouse feel?
|
On June 26 2016 23:06 Cyro wrote:
Wouldn't this make some sensor counts act as 0 or 2 counts rather than 1:1 and mess up the mouse feel?
It is a driver-level software that scales the cumulative count properly, not the half-assed job that you see in Windows pointer scaling. You cannot talk about it in terms of directly converting a number.
You also need to keep in mind that we are talking about 3D rotations here, not a 2D grid.
|
United Kingdom20316 Posts
On June 27 2016 04:26 everythingllbeok wrote:Show nested quote +On June 26 2016 23:06 Cyro wrote:
Wouldn't this make some sensor counts act as 0 or 2 counts rather than 1:1 and mess up the mouse feel? It is a driver-level software that scales the cumulative count properly, not the half-assed job that you see in Windows pointer scaling. You cannot talk about it in terms of directly converting a number. You also need to keep in mind that we are talking about 3D rotations here, not a 2D grid.
You still have the same number of counts on the sensor level. How do you evenly reduce that by say 5%? Technically you can do it by removing 1 count out of every 20 on average, but that's a messy solution. I don't see a better way to do it by modifying the mouse input.
FPS engine converts counts into degrees, you seem to be just feeding it less counts in an inconsistent way.
|
Lack of decimal sensitivity in OW is annoying, but I think it's been overblown. Couldn't you just lower your mouse DPI to compensate, rather than have to install a driver?
|
United Kingdom20316 Posts
Mouse DPI is the "real" fix but it has a few issues. Only a fraction of decent mouse sensors can set DPI freely and lack of proper multipliers means that either your 2d or your 3d sensitivity will be wrong; you have to pick one or the other.
Ideally the game engine would use bigger sensitivity numbers, i think - instead of setting between 3 and 4 sens, we might set between 12 and 16 for the same cm/360. That way you can set 13, 14, 15 and there's no need for the decimal place. This means that high sens users might be using 80 sens instead of 20 sens but i don't think that's a problem.
|
On June 27 2016 05:42 Cyro wrote:Show nested quote +On June 27 2016 04:26 everythingllbeok wrote:On June 26 2016 23:06 Cyro wrote:
Wouldn't this make some sensor counts act as 0 or 2 counts rather than 1:1 and mess up the mouse feel? It is a driver-level software that scales the cumulative count properly, not the half-assed job that you see in Windows pointer scaling. You cannot talk about it in terms of directly converting a number. You also need to keep in mind that we are talking about 3D rotations here, not a 2D grid. You still have the same number of counts on the sensor level. How do you evenly reduce that by say 5%? Technically you can do it by removing 1 count out of every 20 on average, but that's a messy solution. I don't see a better way to do it by modifying the mouse input. FPS engine converts counts into degrees, you seem to be just feeding it less counts in an inconsistent way.
Residuals.
And sense of scale. Yes, on a quantum level it may seem "inconsistent", but you must take into consideration how small each count accounts for the rotation.
Overwatch turns your viewport in multiples of 0.0066 degrees, multiplied by your sensitivity value. Say you have a sensitivity value of 10, that means that the smallest angle you can turn is 0.066 degrees. Overwatch FOV is 103 degrees, which means that on a 1080p screen, at the most exaggerated spot (edge of screen) you are shifting by ~2.266 pixels. At the center of the screen you are shifting by ~0.8796 pixels. (Scale those numbers accordingly to convert to your desired resolution)
Let's say that we are scaling by, in the worst case scenario, 0.99 of the original count. In the worst case scenario, let's say we get 100 individual reports of 1 count. Many tend to mistakenly believe that it will take at least 100 counts before a modification is carried out. Instead, a properly written scaler will fit the closest value between each count by keeping the residual errors so that the next count will be more closely match the scaling factor.
In practice, you are likely to be moving something akin to decades of counts in each action at the finest movement. This makes the report scaling to have even less residuals between each operation.
The reason why people tend to have a stigma for count scaling is because of the half-assed job that Microsoft implemented for their cursor scaling, where each operation is a simple, unconditional, and inaccurate subtraction. This is evident from the fact that the twenty MouseSensitivity scaling factors correspond only to multiples of power-of-two fractions.
|
United Kingdom20316 Posts
There should still be minor visual artifacts from this kind of scaling, especially if you use something more obvious than 99/100 like trying to scale 1000dpi to 850 effective
|
On June 27 2016 23:54 Cyro wrote:
There should still be minor visual artifacts from this kind of scaling, especially if you use something more obvious than 99/100 like trying to scale 1000dpi to 850 effective
Not sure what you mean by visual artifact in this context.
|
United Kingdom20316 Posts
On June 28 2016 00:29 everythingllbeok wrote:Show nested quote +On June 27 2016 23:54 Cyro wrote:
There should still be minor visual artifacts from this kind of scaling, especially if you use something more obvious than 99/100 like trying to scale 1000dpi to 850 effective Not sure what you mean by visual artifact in this context.
The movement won't be as consistent as moving a specific amount every count without exceptions. Here's an example of another unrelated problem that causes moving cursor, dragging windows and turning around in FPS games to look a little bit weird and more blurry - http://www.blurbusters.com/mouse-125hz-vs-500hz-vs-1000hz/
selectively scaling mouse sensitivity like this should have a similar effect. It's a pretty great solution but it's not perfect
|
On June 28 2016 02:23 Cyro wrote:Show nested quote +On June 28 2016 00:29 everythingllbeok wrote:On June 27 2016 23:54 Cyro wrote:
There should still be minor visual artifacts from this kind of scaling, especially if you use something more obvious than 99/100 like trying to scale 1000dpi to 850 effective Not sure what you mean by visual artifact in this context. The movement won't be as consistent as moving a specific amount every count without exceptions. Here's an example of another unrelated problem that causes moving cursor, dragging windows and turning around in FPS games to look a little bit weird and more blurry - http://www.blurbusters.com/mouse-125hz-vs-500hz-vs-1000hz/selectively scaling mouse sensitivity like this should have a similar effect. It's a pretty great solution but it's not perfect
But I thought I already refuted that point with my previous post? Did you have a new point that I missed here?
|
United Kingdom20316 Posts
You'll still get movement that's less consistent than 1:1 tracking (perhaps even noticably so under certain circumstances)
|
I'm confused by what you are trying to say, as I assume that you have indeed read and understood my explanation. Surely you are not just repeating the same refuted argument over again?
Would you like to clear this up in PM? The thread is getting rather cluttered up.
|
United Kingdom20316 Posts
You didn't refute it - but sure, it is
|
BTW, if anyone want to learn more about the nitty-gritty of mice input, and not be misled by the "gamers" conventional wisdom, the folks at the Overclock forum goes pretty in-dept in their investigations:
Sample:
http://www.overclock.net/t/1554228/visualizing-smoothing-in-mousetester/0_100#post_24210511
Some of the excellent software that are often used to make sure the mice input to the games are perfect, include the Sweetlow USB overclocking driver, which on some mice allows 8000hz polling, as well as the Interaccel driver that was the subject of this thread. MouseTester and MouseMovementRecorder are also bread-and-butter for testing the mice input, since the Enotus Mouse Test is in fact entirely useless for getting any actual information with regards to mice performance.
|
|
|
|
|
|
EPT
