TheNoobPolice

Well it's not really scientific, one of the main reasons is simply because Windows is not a RTOS and is objectively bad once timings get tight (note: there is one timing procedure called the Performance Counter which usually has 10mhz precision these days (it depends on hardware), but this is only really used for elapsed time measurement and can't be "spun" to delay a thread without high CPU usage, so most timing functions called by programs will use lower-resolution procedures). A variance in poll time affects what distance is reported (i.e relative to what should be reported) when the OS gets data from the mouse. There may also be some per-mouse / on-board firmware differences between the selected polling rates which I don't have any insight on as isn't an area I am directly familiar with, but the way it generally works is the USB device has to flag an interrupt to the CPU in order to process any data sent/received and this can be deferred/delayed by the CPU for any reason - and in a Windows environment these delays happen a lot. People have ran tests in other environments using the same USB spec and they can observe microsecond precision, so USB itself is not the issue here. In Windows, if you use a mouse with 8k polling, for example, you will see totally crazy input cadence. Windows doesn't handle it well enough even just to update the cursor position every 125us, and especially games don't. A lot of the "better smoothness" difference people feel with 8k is actually just dropped packets - an objectively worse performance that they convince themselves is better - instead of every input arriving 125us, you will get some that arrive in like 40us or faster and some that take more than 500us, and any game most likely won't be able to process the former inputs unless it does a buffered read of raw input (which is by no means standard / common, and this by design pre-buffers inputs into an accumulator outside of the game which totally misses the point of what people think high hz is doing for them in-game anyway). Anyway, I digress. I still use 500hz because it pretty much works well in all games no matter how they get input, results in low CPU thread usage, and is always going to be significantly above the max of any game frame rate I play and my monitor refresh rate which is the only important barometer imo.

Have you updated the Allow Asset mod file? Depending on when you last updated it, it may need a new version also. That said I wouldn't be surprised if something has gone wrong because the last round of patching has been awful, so many things have been broken.

Read here

You only need to enter DPI in the app for the velocity chart (since it charts real-world meters per second as units) and / or if you want to measure true DPI accuracy / deviation (can also be done on this website). Your mouse has much better performance than any of mine as far as it's SPI timing (jitter) and counts distance consistency, probably why it also drifts far less than any of mine do. You plot would not improve much if at all from any smoothing as it's remarkably un-noisy (most likely because there is some internal smoothing applied in the sensor / firmware which is why the plot is so nice). So basically, although this is a big issue for you personally, you probably have less than or equal to the lowest drift of any modern mouse available, and I once again refer to my previous advice of you really should find something else to worry about. If anyone tells you they are getting less drift they are probably either not testing in real-world conditions or just talking nonsense.

I’ve seen this said before, but just to note it isn’t true that this is the cause of this. Your wrist does indeed move left to right and back in an arc, but the sensor is fixed in its position in the body of the mouse, so rotates to exactly the same angle made by the arc at all times, so from the sensor’s perspective that can only read delta x and delta y relative to it’s own orientation, it is simply moving horizontally. As long as the sensor stays in contact with the surface and isn’t lifted, you could move it around in any mixture of circles or curves and lines and put it back to where it started in the same orientation, and mathematically the cursor would always be back in the same position. The reason it doesn’t work like that is just because the sensor / firmware combination is fundamentally not an accurate technology This test shows a lot of optical sensor drift even when moved by a machine that keeps the mouse fixed in the same orientation - even the G900 drifts a little and there hasn’t been any major technological reinvention of optical sensor tech since then.

Not easily. I just quickly added the code in a test build of a driver I contribute to, which requires a development environment (and it isn’t open source anyway). I’m not aware of any method using windows hooks to block the native mouse input after reading raw input to then send out modified output to the cursor, because the same hook would block the modified output also, so to do this with the cursor would require a kernel driver (to my knowledge) that doesn’t see it’s own output. I could just build that function into an .exe with a free-to-use signed kernel driver library like Interception, but then my .exe wouldn’t be signed and any anti-virus would probably immediately panic and mistrust it these days. I’d rather just share the code and anyone who wanted to try it build it themselves locally, which given you don’t code is a bit of a stumbling block. But it wouldn’t solve your kind of drift fully anyway, and neither does an exact replication of the code you linked before - it just helps mouse they have very noisy distance input feel a little more stable. I’d run MouseTester on your own mouse first to see if it would be any benefit.

Ok, well, skimming the code, the "fix" implemented is a filter that ignores relative deltas of a seemingly arbitrary large value. Effectively a smoothing algorithm. This has some merit if you don't mind smoothing. It could potentially minimise some kinds of drift because you reduce counts distance outliers and average out the motion (i.e a low-pass filter) but this always adds motion delay (which is not "latency" in terms of an input arriving later to the PC, rather the output is effectively applied a reduced sensitivity as your hand speeds up and increased sensitivity as your hand slows down; like negative accel on speeding up, positive accel on slowing down). That said the approach is rather cumbersome IMO, a more elegant function for mouse input would be to use something like an exponential moving average (I like Brown's algorithm personally) since it is very simple (read computationally efficient) compared to something like a Kalman filter, and compared to a simple 3 or 4 sample moving average is weighted towards the more recent data which is preferable for real-time input systems (read responsiveness). This function I just wrote in c++, for example, feels rather nice typedef struct vec2d { double x, y; } in, out; inline void emaSmooth(vec2d &in, double coeff, double magnitude) { static double EMA = 1; EMA = coeff * (magnitude - EMA) + EMA; double ratio = EMA / magnitude; in = { in.x * ratio, in.y * ratio }; } vec2d in; in = { raw.x, raw.y }; // where the raw [x,y] is a rawinput struct defined elsewhere vec2d out; out = { 0, 0 }; double coefficient = 0.5; // "1" is no smoothing, increasing towards 0 double distance = sqrt(in.x * in.x + in.y * in.y); emaSmooth(in, coefficient, distance); out = { in.x, in.y }; You can see how this tightens up the inputs of my Razer Orochi v2 using MouseTester. This is the raw x-axis input moving the mouse in circles around 5-10 counts/ms. You can see some outlier inputs hitting 15 counts distance or more, and it's rather noisy... and this is with the above smoothing algorithm with a coefficient of 0.5, which is a lot "nicer" plot... So it's possible to alleviate some causes of drift by smoothing the input in a manner that makes sense for the kind of input it is, but you will always sacrifice technical accuracy of the true sensor output, and it's unlikely to fix drifts caused by surface variation or other anomalies that tend in a persistent direction. I'm of the opinion that a little mouse smoothing isn't such a bad idea, but you're not going to hear that from the mouse input purists.

I don't think anyone should run an .exe from a mega link. If it's not open source and linked on Github or similar, and there is nothing particularly interesting about the value of how much the cursor drifted IMO. You can see on the screen how much it drifts after all, you don't need to accumulate the mouse counts via Raw Input to do that, since 1 count = 1 pixel * WPS multiplier you could just check the cursor position before and after. For what it's worth my Razer Orochi v2 mouse on my current mouse pad, drifts up much faster than yours does. I'd just suggest you stop worrying about this very normal issue with every mouse ever made.

Also the (rather sensible) argument of "the default value that the players of our direct competitors are most used to will be the path of least friction for our game" plays a part. Exactly why you also see .022 as a default yaw value in many off-shoot engines since Source, and why Activision/Blizzard have standardized to .0066 in all their FPS games

Your feelings cannot be debugged though. At the risk of sounding overly facetious, probably for the same reason I used to be able to party until 4am and still play Sunday league at 9am, and nowadays would need 2 days off work to recover lol. Our minds and bodies change over time. It doesn't usually matter what Windows sensitivity you use for most games that read Raw Input, but you should not Windows slider higher than 6/11 anyway. Any values below are fine but there is some wonky extrapolation / rounding in the code above that . You can see that in this paint test here: This a scripted perfect circle input with remainders properly carried via integer truncation (the same way a mouse sensor would - you have to do this otherwise you get drift just due to desktop pixel granularity). You can see the errors in the more jagged output on the left. This has been present since before XP at least and the code has never been changed by Microsoft. These have been traced over themselves at least a dozen times, so the interesting thing is that the 8/11 errors are also consistent (i.e. always creates the same distortion in the same way for the same inputs). This is perhaps why you were still able to use 8/11 fine and just learned how this error feels. Here's a Logitech script anyone can use to test it themselves (or to check my math) EnablePrimaryMouseButtonEvents(true); counts = 4 -- Distance sent on each angle. 4 for 6/11, 2 for 8/11 etc scale = 2 * math.pi / 360 carryX = 0 carryY = 0 local int = function(v) if v < 0 then return math.ceil(v) else return math.floor(v) end end -- turn on ScrollLock, then just hold left mouse button in paint function OnEvent(event, arg) if IsKeyLockOn("scrolllock")then repeat if IsMouseButtonPressed(1) then repeat for i = 1, 360 do local angle = scale * i local x = (- counts * math.cos(angle)) + carryX local y = (- counts * math.sin(angle)) + carryY MoveMouseRelative(int(x), int(y)) carryX = x - int(x) carryY = y - int(y) Sleep(1) end until not IsMouseButtonPressed(1) carryX = 0 carryY = 0 end until not IsKeyLockOn("scrolllock") end end

This is true of all mouse sensors with current technology, this is not something new that happened. Drift will always occur to varying degrees. Some are worse than others, and some drift in different directions than others. It is also affected by pad surface, sensor type, firmware implementation, DPI resolution etc etc. It's not really an issue for most users, because people who are interested in aiming accurately normally use sensitivities or aim styles that require lifting and re-centering the mouse, and this technique is not usually problematic for gameplay in 3D shooter games where aiming accurately tends to be of interest. It is particularly a problem in games like Osu! though, which rely on 2D linear displacement and whereby a lifting technique is problematic. Hence why the top players use a Stylus usually. None of this is anything to do with the Windows version or USB spec, and it is not something you can fix or troubleshoot (besides ensuring the sensor is clean and that you don't have an uneven / dirty mouse pad, as these exacerbate the issue)

Yes, Beenox introduced the Relative mode a few titles ago as a way for Battlefield players to easily convert from it's Uniform Soldier Aiming option with the same default scaling multiplier.

I primarily blame Epic for a lot of this as going back quite few UE frameworks now, they have persisted with strange defaults, like Vert- for game world FOV scaling which makes little sense; why would anyone move to a wider screen monitor and expect the top and bottom of the image to be cropped instead of the horizontal view expanded to fill their new screen? It is better to just not support higher aspect ratios than to make a mockery of them. Thankfully many game devs do change that one, but we see a lot of camera smoothing left enabled as you know.

It's better for games to not tie the FOV option to camera turn-rate for "look" or what is usually hipfire etc. I don't buy for one second that any uninitiated user expects their 180 turn / navigation mouse movements to change when they change the Field of View in the graphics options, and it's annoying if you just need to lower the FOV for say, performance issues (which are abundant in this game) and it changes your mouse sensitivity etc. So if you like being able to tweaking the FOV as you play for whatever reason, it's best to disable the FOV mouse sens scaling.

Unless you want to avoid this precisely due to the case of doing additional work in the event the devs patch it, I'd suggest since the site support is dependant on using a mod anyway, that you form the basis using the mod which both fixes x and y scale disparity, removes FOV scale (which is a good thing) and also downscales sens to 1 multiplier (since it is too high by default for any reasonable settings). Actually, the xy mod doesn't disable FOV scaling and doesn't seem to affect aiming xy relationship, only "look" sens as far as I can see, so no point in the above.

Just a tip; the FOV line in the config file won't appear unless you have changed the FOV in game.

The aim punch / flinch is indeed awful. Makes 1v1's very frustrating. I hope that gets tamed a little.

In most cases, accessing scope or ADS values from one game to another is a Premium feature of this website.

It wasn't added for this game per se, the sliders are a legacy setup from older games and sometimes there isn't anything in the new game to bind them to (or they could be considered placeholder in case the design teams add them later). This was the case for BFV also. It's often easier to leave in a function than to remove it. Only BF1 had an actual 1.0x ADS magnification option (BFV conceded and made it 1.01x). All the other games have always had a varying degree of magnification for "iron sights", "close range" or "1x" regardless of the number stated and this is not unusual - in most military shooter games the target sizes at the hipfire FOV's people tend to favour are not suitably large enough for the distances the designers build the geometry scaling around, so especially for games that are to be played on console (where players are usually sat much further from the screen) not reducing the FOV when aiming just produces a bad experience. The only reason it worked in BF1 were that the engagement ranges were on average much closer for a Battlefield game, and the manual 3D spotting made enemy visibility easy enough to access to get away with "no zoom".

if I don't play for a week or so the sens can feel much faster when I get back to it. Likewise, if I am particularly caffeinated on a given day, it can feel far slower than usual. The short version is no one can debug your feels, but sensitivity is measurable. If the cursor moves the same distance on the screen as it does on the pad day to day then the variable is you, not the mouse. e.g if you are at 400 DPI, then 1/400th of linear inch movement with the mouse sends a count of 1 to the operating system, at Windows 6/11, this is converted into 1 pixel displacement. So if you are at 1080p, then you need 1920 "400th's of an inch" of mouse pad movement to move from one side of the desktop to the other - therefore, 1/400 * 2.54 * 1920 = 12.192cm on the mouse pad. If it's within +/- 10% or so of that it's probably just the natural variance of the surface or a little DPI deviation (which you can test on this site), but this would be consistent and not changing day to day. You can just use a tape measure on your mouse pad to confirm it's the same even if it feels different to you. Also, goes without saying that you'd need Enhance Pointer Precision unchecked in mouse settings to test like this

That's going to be one hell of a for-loop lol Yeah it's a really innovative feature idea, will be a great time-saver also.

That's excellent, it didn't occur for me to have that part of the process embedded in the site also but it makes total sense - that is how I originally found my preference from all the BF4/1 scopes I had set. I just plotted points and adjusted the variables to dissect them all

As DPI Wizard said, because the point along the radius (i.e the monitor distance) of a circle and the arc length (and therefore also the velocity at said point on the radius) have a consistent relationship with one another, this is more of a convention change as defining whether we interpret those quantities as velocity or arc length instead, because you can always create the same functional output regardless of which quantities you work with as long as you adjust the variables to compensate. I would argue that monitor distance is a better barometer in our gaming use case, because I believe more gamers have a better grasp on this concept than they would do the others. I'm glad that my suggestion got you to look at things more though and I'm actually more interested in your second point, which is finding a formula to calculate one-size fits all values for the limit or power variables. I did not attempt this in my suggestion. If someone said to me "what limit or power should I use?" my answer would have been "how the hell should I know?" The idea was to allow customisation and put this in the hands of the user instead - I used a simple power curve for the coefficient because it allows a great deal of flexibility and is very simple mathematically, but this is fundamentally just defining a curve that goes from 1-0 on an x-axis of "zoom ratio", and you could replace this curve with anything. For example, one of my favourite shapes for a natural rate of change (such as when using acceleration) is the "sigmoid function on log-log plot" I have used in Raw Accel. We could use that in the same way like this - shown with the current coefficient curve method for comparison (I removed the cap because we omitted it from the site implementation anyway as wasn't useful.) https://www.desmos.com/calculator/xtn91ohke1 Would this feel more natural? One could make all sorts of arguments about the natural logarithm and human perception of change being more logarithmic than linear or exponential, and apply those arguments (probably incorrectly) to this, but ultimately I feel like it's all down to individual perception and prior experience anyway. But would be interested to see if you find other approaches that might arrive at sensible values more automatically for the existing method.

I think you’re right - from what I remember Diabotical has a multi-threaded option get mouse input, and the only reason to do that would be to get more frequent updates for e.g clicks vs for deltas and then coalesce at the start of each simulation frame. I feel like it’s not going to really make a difference in a real-world situation to anyone’s experience other than when testing with scripts though. Mouse movement data itself is just a serial stream so there is no point trying to multi-thread the acquisition of movement data. And I agree that the UI aspect of all Windows mouse settings definitely needs improvement. There is also still a legacy bug with the scale factor when EPP is off and the multiplier is above 1 (some error with carrying remainders or extrapolation issue as the output is inaccurate - didn’t bother to reverse engineer what exactly, just can see that it’s incorrect). I think it’s fine to have a slider with discrete notches for easy-mode, but no reason to not allow for manual input of float values also to allow scaling of DPI to any value without needing 3rd party kernel-mode filters. There should also be the option to adjust sensitivity by direction (vertical, horizontal, diagonal etc) by either individual component or whole vector built into the operating system, if for nothing else but adequate accessibility and for power users. Anyway, last point is they’re some of the tightest distance plots I’ve ever seen you’ve just posted. Do you have a Razer motion sync sensor by any chance? I can only create plots that look that good if I write a smoothing function to put the mouse input through…

The pixel ratio is a function of the in-game sensitivity, the FOV, and the screen resolution only. No other variables affect it. Given that it is not very convenient to change your screen resolution or FOV for this issue alone (given that there are pervasive consequences attached to those changes) you would simply reduce the game's sensitivity value instead, as this can be compensated directly for with DPI increase with the only other action requiring reduction in windows cursor speed slider if it bothers you.