TheNoobPolice

A new feature is added to the calculator that enables you to reverse calculate your current sensitivity. This functionality helps you identify the most suitable method, coefficient, and scale to align with your existing sensitivity settings. It simplifies the process of finding the precise matching parameters to effectively maintain your preferred sensitivity.

The "Reverse" button is positioned above the selected game in the "Convert from" dropdown menu. Initially, it will appear grayed out and inactive until specific criteria are fulfilled:
The selected aim must be "All" and be comprised of multiple sensitivity variables. For instance, it won't function for games that employ various aim calculations but all utilize the hipfire sensitivity. The calculation for the "All" aim must be error-free for the primary sensitivity. Errors related to ADS and scope aims being out of range won't affect this condition. When these conditions are met, the "Reverse" button will turn green. The sensitivity, FOV, resolution, and other parameters you input for the "All" aim will act as the foundation for the reverse calculation, necessitating an exact match with your current settings.

When you click the "Reverse" button, a popup with all the aim sensitivity will show. Note that aims that are not ADS or scope will not show up. Some sensitivity settings are shared between more than one aim, if so a dropdown box will show next to the sensitivity and you need to select the aim you are entering the sensitivity for. Enter your current sensitivity into corresponding boxes, vertical sensitivity is also supported for reverse calculation. You do not have to enter a value into all the boxes, but it is recommended for best accuracy. Once all values are entered, clicking "Reverse!" will generate a table presenting all suggested calculations based on your inputs.
If you are converting from a game with both ADS and scope sensitivity, you will see three tables: One for the best match for both ADS and scope combined, one for just ADS and one for just scope. If the game only has ADS or scope, only one table for both ADS and scope will show up. Vertical sensitivity will show up at the bottom.

 
The Monitor Distance methods will only show up in the ADS and scope table if the coefficient and scale is identical for ADS and scope.
Click the "Use" toggle for the matching method(s) you want to use, then click "Apply" to use the settings for your calculation.
If you find anything not working as expected, post it here. Note that you will not always get the expected result because of rounding.

We now have a Discord server for the community, join it to both discuss stuff and get support!
https://discord.gg/yY3PAg6r32

View full update

Pixel ratio is calculated by dividing the sens- scaled yaw value (I.e degrees per count) by the amount of degrees in the centre of the screen over 1 pixel’s distance at any given FOV, which can be found as follows:
e.g for Counter Strike at 1920 x 1080 res:
yaw = 0.022 degrees;
sens = 0.5;
horizontal res = 1920 pixels;
horizontal FOV = 106.26 degrees;
Degrees per pixel distance = 2 * atan(tan(hFOV / 2 * pi / 180) / hRes) * 180 / pi = 0.0796 degrees;
Pixel ratio = yaw * sens / degrees per pixel distance = 0.138;

With mouse input we convert a physical distance to a virtual distance. To do this we normalise both to virtual units.

The "count" or "mickey" is a virtual unit defined by the DPI. If you are at 400 DPI, then 1/400th of linear inch movement, sends a "count" of 1 to the PC. 

At the PC side we convert these virtual count units to output distance units. This is either in pixels in 2D, or angles in 3D.

The angles in a game is indeed defined by a "Yaw" value e.g. Source engine by default has 0.022 degrees - this means that 1/400th of an inch (1 count) from our mouse movement turns 0.022 degrees (the base yaw) in the game. These are our normalised input and output virtual distances from your hand motion.

The sensitivity of any function is the ratio between the output and the input, therefore we can say it is a multiplier. Since we already have our normalised values, then we know the sensitivity of "1" is an input of 1/400th of inch on the mouse pad, and an output of 0.022 degrees, so a sensitivity of "0.5" would be an output of 0.011 degrees for the same input distance.

This can always be calculated as outputAngle = yaw * sensitivityFunction() * counts.

Therefore to solve for counts instead, we do counts =  outputAngle / ( yaw * sensitivityFunction() ).

Example; we have a game that has a yaw value of 0.014 degrees, sens of 1.2, and we're at 1600 DPI and want to turn 30 degrees. How many counts do we need to turn to this position?
so we have 30 / ( 0.014 * 1.2 ) = 1785.71.

To convert back to physical hand motion, it's therefore:  1785.71 / 1600 = 1.12 inches on the mouse pad turns 30 degrees in the game.

You have to always use the same units for both outputAngle and yaw value obviously. I use the term "sensitivityFunction()" because the value exposed to the user is not always linear like in Source, so this multiplier would be the return value of whatever formula a game uses to represent this to the player, which is highly variable and completely arbitrary so is one of the main reasons for this site's existence.

Read here
 
 

You are going about this in an overly complex way. If you want to increase vertical sens without changes in direction and without using acceleration you would really need to use something like the Bias mode I added to Custom Curve.
In Raw Accel you can do similar but you kind of just have to "hack" it using the LUT mode and anisotropy by using an "instant" acceleration to a cap that all occurs below minimum input speed.

You could set it as follows:

LookUp Table (Sensitivity mode):
1e-17,2;
1e-16,2;

Sens Multiplier = 0.5
Y Range = 2 * desired y/x ratio - 1 = 1.84972170686 in your case


This creates the same graph as your y/x ratio version, but does not change diagonal directions (This shows what usually happens).

This method works because we create some invisible instant acceleration between sens 1 to 2 and the range function has a formula of:
(acceleratedSensitivity -1) * (rangeX + (rangeY - rangeX) * (atan(|y/x|)) / (pi/2)) + 1

or more easily understood as:

"A single sensitivity applied to both axes, that is linearly scaled to each axes configured sensitivity value by the ratio of input angle to 90 degrees"

The transition across angles would be entirely linear in Raw Accel, so an input of 45 degrees would have a sens of (1 + (desired y/x ratio -1) * (45/90)) = 1.212430426715, and an input of 22.5 degrees would have a sens of (1 + (desired y/x ratio - 1) * (22.5 / 90)) = 1.1062152133575, but there is only this one sensitivity applied to both axes components at all times so directionality is preserved - increasing vertical sens in this way does not make near horizontal motions less stable by "pitching up" your crosshair like what happens with a y/x ratio change.

Using legacy threshold-based angle-snapping is a bad idea since it is extremely flawed and simply obfuscates angles below the set threshold - which is doing nothing except reduce the fidelity of input. There could be less compromised ways to facilitate a larger / more forgiving angular window to move along an axis, but none that are available at the moment.

ohhh okay. Thanks a bunch for explaining everything to me and great work on that program, I'm glad I bought it way back. And yeah, that '1 sec' thing really threw me off, i was thinking im sure i didnt notice a delay in input hahahaha. Have a great day dude

Yes! Well, everything that actually affects your mouse input. The GUI which is just used to visualise and apply settings is in user space.
Obviously not as that would be ridiculous lol. When you press "Apply" all profile settings are written to the driver, and there is a 1 second delay until they are operational. There is no delay in use.

Why would it be required to scale sens and not DPI? If you want a smaller turn increment, just set sens to the lower value of whatever the change is. You could load the rawaccel profile only when playing the game or even script it trivially with something like Autohotkey to load both the game and the profile automatically, this is much safer and would work better than trying to modify game memory using cheat engine.

I've updated the calculations using the latest version of the mod NoMouseSmoothingReducedScaling. I've also removed the NoFovScale entry as there's basically no reason to use it over the other.
The sensitivity was changed significantly (1/3 of before), and the X and Y are now the same.

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.

You're correct. It's just that some people miss the human factor in it and others deny modern sensors having any drift, so I guess I was just covering the possibility.

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.

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.

 

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.

ADS and scopes added, but only for "PreserveFOVScaling" as this is how the base game actually works.

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

This also goes for all the sensitivity values, and they will appear in a random order 😵‍💫

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.

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".

The Optimum Tech video on DPI latency / input lag used a flawed methodology to test movement latency as there was no normalised output distance for each tested input distance (DPI’s). He measured movement resolution, NOT latency. There is no input lag or latency effect at all for different DPI values.

Imagine Usain Bolt was sprinting against a 5 year old and they both set off at exactly the same time. If we apply the same testing philosophy that we see in that video, we would only measure the time until the first foot landed on the ground, and because of their tiny little legs and narrow stride pattern, we would therefore conclude the 5 year old was the faster runner.

Suffice to say, it’s not the time until first point of data, but the time to a significant target location to define “input latency” i.e input to “something”. Of course, a higher DPI would make “some first movement” faster than a low DPI at the same hand speed, as that is the definition of DPI, but presuming you have the same effective sensitivity in a game between DPI settings (i.e the same 360 distance) then the distance turned in-game is smaller for that first movement, so additional inputs (which take additional time!) would be required to turn the same distance as only one input would do from the lower DPI mouse. Once the minuscule amount of time has passed for the lower DPI mouse to send data, it updates to exactly the same position as the higher DPI mouse at exactly the same time. Saying there is a different “sensor lag” or "latency" for the natural effect of DPI is misleading - the path the data takes to your pc is exactly the same.

In other words, there is no difference in input lag for different DPI values. What was tested is easily calculable with simple math and isn't required to test in this manner. If you could set the DPI to "1", and moved your hand at 1 inch per second, you would see 1000ms pass before the count was sent and their measuring devices registered some movement. This does not mean there is 1 second latency in the mouse input.

Yeah, the challenge is that it's not possible to do mathematically, it has to be done programmatically. So it basically has to iterate through tens of thousands of percent/power/scale combinations to find the best ones across all aims. I will make it so it tests both ADS alone, scope alone, and both combined.
This is the work in progress, when it's done it will be in a nicer layout for the result, and have the ability to click the conversion you want to use