If you go into Windows settings > Mouse > Additional mouse options > Tab: Pointer Options, there’s an option called Enhance pointer precision.
I know what this does and how it works but I want to know if this option is also active in Overwatch when enabled.
Yes, OW doesn’t change that. You should definitely have it off/unchecked when playing any FPS.
I found this thread that says Overwatch uses raw input (scroll down for Dev reply):
http://web.archive.org/web/20151101013626/http://us.battle.net/forums/en/overwatch/topic/19615281339
so that option shouldn’t affect Overwatch but that was at beta and maybe that changed? I want to know how that comment holds up in 2021.
Overwatch does indeed use Raw input, which ignores windows pointer ballistics, including EPP.
Now, one of the big myths about raw input is that it is actually RAW INPUT from the mouse hardware, and this is not actually the case. It is still subject to a number of different OS level modifications including DWM compositioning and system-wide DPI scaling (even in fullscreen exclusive!). This is fairly easy to prove by using the “application compatibility” settings. If you enable/disable per-process-dpi or HighDPIAwareness, your input response will change slightly with each setting. If raw input actually read mouse X/Y deltas directly from the mouse, this shouldn’t make any difference.
All raw input really does is bypass windows pointer ballistics - which is the “mouse settings” on your control panel, including the slider for mouse speed and the enhance pointer precision checkbox.
You can test the effect of EPP yourself by turning it on/off and comparing both settings. If it were active, it would make your input drastically different. Try the same test again with a game like CS:GO or aim-lab that allows you to select “windows input” instead of “raw input” and you will see how much differently it moves with EPP on vs. off.
In general, it is advised that you should have it off, but you are correct that it shouldn’t really matter for raw input games.
Wow that’s a pretty extensive and useful answer. I wish I could mark it as answer. Thanks for the info! That means I can keep this option on which is nice to have in Windows and the desktop (not in Overwatch naturally).
Btw, are you a (game) developer? That’s some oddly specific but interesting info.
No, but one of my personal projects (obsessions?) has been to devise a way to disable the physical-ppi scaling that windows 10 uses to correct for the different pixel densities used by different monitors. This is something intended to ensure text looks clear and legible no matter what monitor it is displayed on, but unfortunately due to how text-dpi is linked to mouse input in windows, it has a minor (arguably trivial) impact on how mouse input works that causes it to behave slightly differently on monitors of different sizes/resolutions. Most people would never notice the difference, but after a decade of using the exact same settings I am hyper-sensitive to anything that makes it respond differently than how I expect.
And once you know it exists, you can never un-know, as the saying goes.
Thus, I have spent an extensive amount of time reading microsoft documentation on how mouse input is collected and utilized in windows 10 in my many (unsuccessful) attempts to figure out how to disable it.
Embarrassingly enough, I played OW for years with this enabled. Turning it off remarkably improved my aim.
As a general recommendation I recommend keeping enhance pointer Precision feature for Windows turned off when playing any online game. While it is true that OverWatch uses the raw input data from the Mouse, having that feature turned on does consume RAM and can cause very slight performance issues in some systems
No it doesn’t. Overwatch and basically every FPS made after 2005 uses Raw input.
Raw input explicitly ignores enhanced pointer precision regardless of its state. Neither consumes any addition RAM, nor causes performance issues.
Sorry I mistyped my post I meant to say it does not use enhance pointer precision
Neither raw input nor enhanced pointer precision use more RAM, though.
If this game required more fundamental aiming ability more people would switch to controller (b/c of aim asst).
Let’s take it a step higher, why on earth would you need this to enabled in the first place? Just turn it off.
Because it’s nice to use on the Windows desktop.
What IT company do you work for?
It consumes more RAM? Where did you learn that? How did you become a “tech support”?
First of all!
Sorry for raising this topic from the dead, but…
Since this scaling-problem I mentioned here ended up being
and because
I thought maybe people who visit these forums who might be suffering from this exact issue POSSIBLY without even knowing it might appreciate having it posted here.
Fun fact: it turns out I was 100% wrong about the cause of inconsistent windows 10 mouse input being tied to monitor DPI/PPI.
It is actually the result of how the windows 10 virtual desktop uses a different kind of raw mouse-input format compared to most games (3D game mouse = almost always relative input, desktop mouse = absolute input) combined with how absolute raw-input is still scaled by desktop screen resolution!
Not because of microsoft’s wonky hardware-measured screen pixel density scaling as I had previously thought.
What is relative mouse mode?
Relative Mouse is a method of translating mouse movements as a delta from the last mouse position rather than a move to an absolute position on the screen. This type of mouse control is used in many CAD/CAM, Visual Effects and First-Person Gaming software.
TLDR summary of the difference between the two
From the Windows documentation on raw mouse input API
https://docs.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-rawmouse
if ((rawMouse.usFlags & MOUSE_MOVE_ABSOLUTE) == MOUSE_MOVE_ABSOLUTE)
{
bool isVirtualDesktop = (rawMouse.usFlags & MOUSE_VIRTUAL_DESKTOP) == MOUSE_VIRTUAL_DESKTOP;
int width = GetSystemMetrics(isVirtualDesktop ? SM_CXVIRTUALSCREEN : SM_CXSCREEN);
int height = GetSystemMetrics(isVirtualDesktop ? SM_CYVIRTUALSCREEN : SM_CYSCREEN);
int absoluteX = int((rawMouse.lLastX / 65535.0f) * width);
int absoluteY = int((rawMouse.lLastY / 65535.0f) * height);
}
else if (rawMouse.lLastX != 0 || rawMouse.lLastY != 0)
{
int relativeX = rawMouse.lLastX;
int relativeY = rawMouse.lLastY;
}
Basically this is the important line to point out
int absoluteX = int((rawMouse.lLastX / 65535.0f) * width);
int absoluteY = int((rawMouse.lLastY / 65535.0f) * height);
If you are fluent in math it should immediately be apparent that different resolutions can and will give you different float values for absolute mouse-input deltas!
Therefore, if any truncation or rounding occurs during any part of the chain where mouse deltas are passed from the DWM-renderer to the game, you might get single pixel inconsistency errors (ie your swipe moves 33 pixels instead of 32 like you expect).
Tiny, sure!
But this limits maximum precision and is potentially compounded by motions that involve repeated direction shifts (such as trying to track a target that is rapidly moving back and forth).
If you have two monitors in a multi-monitor setup and they use different resolutions, your mouse-input will be slightly different as soon as the non-visible cursor on your virtual desktop crosses the border between monitor spaces.
Why?
Windows renders a “virtual cursor” on the “virtual desktop” and keeps track of it even if the flipmode de-activates desktop inputs or desktop rendering (for some reason). This virtual cursor doesn’t actually DO anything itself. But it does move along with your in-game cursor.
If you remember a long time ago, there were a few versions of Overwatch with a bug that would occasionally cause the desktop-cursor to render visibly in-game in the middle of your screen, and this would sometimes happen if you alt-tab in or out several times in succession.
When this happened, any movement in-game would make this cursor move outwards from the center, but only briefly. It would appear “sticky” and jump back to the center almost immediately unless you move it very quickly.
This is basically what windows/DWM is doing “behind-the-scenes” all the time, and probably explains why the raw-input glitch occurs. Since your “virtual cursor” on your desktop constantly re-centers itself, based on mouse polling rate, it clearly wouldn’t happen all the time, it tries to park in the middle.
However IT IS possible to briefly cross the border between monitors on the “virtual desktop” before it re-centers the “virtual cursor” during a very rapid movement. This COULD result in a different calculation being applied to inputs during ANY part of a motion where the virtual cursor was technically on a monitor of a different resolution.
I was able to partially verify both the problem and solution by forcing the use of specific raw mouse input modes using registry keys.
(useful for testing but NOT recommended as a long-term solution due to numerous potential compatibility issues with other games)
Absolute mode forced + different monitor resolutions = noticeable pixel error inconsistencies
Un-forced(default) + different monitor resolutions = subtle pixel error inconsistencies
Relative mode forced + different monitor resolutions = no inconsistencies observed
Absolute mode forced + same monitor resolution = no inconsistencies observed
Un-forced(default) + same monitor resolution = no inconsistencies observed
Relative mode forced + same monitor resolution = no inconsistencies observed
This is, however, based 100% on subjective observations and I have yet to work out a way to determine this with empirical evidence.
However, I’ll be honest here: I have spent months/years trying to solve this problem with unnecessarily complicated and unsuccessful solutions.
For now, I am fairly satisfied that this simple and un-intrusive method resolves the issue, so I think I will leave the task of obtaining hard-proof to someone else.
BASICALLY
If you use only 1 monitor when you game it shouldn’t affect you at all.
If you use 2 monitors of the same resolution (regardless of scaling) it shouldn’t affect you at all.
If you use two or more monitors AND they have different resolutions, this MAY affect you (depending on the game)
Apparently, it ONLY affects raw-input games since relative/absolute mouse-inputs are treated very differently; it wouldn’t make any difference in a non-raw input game because both absolute and relative inputs use some kind of screen-size based scaling.
99.9% sure CSGO works this way
~90% sure about Overwatch
BUT HOW DO I FIX IT?
Yeah, sorry, super long post I know.
Simple answer - if you have multiple monitors all you have to do to prevent this glitch is switch the desktop resolution of all your monitors to the same value when you want to play a raw-input game. You don’t have to keep them that way all the time.
Example - I use 1920x1080 on my primary monitor and have a 3840x2160 secondary monitor.
To avoid this inconsistency, I have to set my secondary monitor to 1920x1080 while I am playing a full-screen raw input game like Overwatch.
When I am done, I just set it back to 3840x2160 afterwards.
I’m also pretty sure it doesn’t matter what resolution is set when the game first opens (unlike DPI scaling in many cases). Either load the game first, then switch all your monitors to 1920x1080 (or whatever resolution you play on) or switch before loading the game, it shouldn’t make any difference. As far as I can tell, the scaling (like 100%, 125%, or 150% etc.) doesn’t seem to matter, JUST the resolution.
Kind of a pain to do this every time (maybe somebody can come up with a tool to automate this?), but it’s a very simple fix and seems like it FINALLY makes it feel consistent.