TheNoobPolice

It's not MDH, It's MDV, because that is the default for the Battlefield Uniform Soldier Aiming function that you say you want to emulate in Apex.

You'd set the calculator up like this:

I thought I'd share a formula I have used that matches my own preferences pretty perfectly for a "one size fits all" scope zoom scaling, (an updated "uniform soldier aiming" if you will, for games that use many scope zoom levels). As many of you agree focal length or "0% monitor match" is the mathematically principled way to scale, with arbitrary monitor distances effectively being just a hack to mitigate the natural slowdown effect that zooming-in creates when using focal length scaling. While playing games like Battlefield 4 / 1 or the newer Cod's, I always ended up with the coefficient set to 0% for low-zoom scopes, and then each scope's individual slider gradually increasing in sensitivity the higher the zoom level. It was always fairly apparent to me that commonly used monitor distances like vertical 100%, 133% or especially 178%, are too fast at low-mid zooms of irons / red dots etc, whereas focal length scaling is always much too slow at high zooms / sniper scopes. I think this experience is also shared by many others. So I have taken the monitor distance hack a step further to allow what is effectively a dynamic coefficient via a simple calculation based on the start and end FOVs. This is nothing new of course, but unlike other variable methods like Viewspeed or Jedi's trick that also do this, it scales much more broadly by comparison. Converging to focal length scaling for the lowest zooms, and approaching an asymptotic monitor distance limit at an "infinitely high zoom" (or a hard cap). Here's a graph of the formula with regular 133% vertical monitor distance and focal length scaling for comparison. By replacing the monitor distance coefficient with simply Limit*(1-(ZoomFOV/HipFov)) the coefficient approaches a value of zero when the two FOV's are close together, and gradually approaches the limit the more they diverge. https://www.desmos.com/calculator/rlrmeml65f If you enter the hip and zoom vFOV's with the sliders, the graph will calculate a monitor distance based on the variables entered for any games ADS FOV level exposed on this site. A limit of 2 would mean the maximum monitor distance is 2 for when "zooming to infinity" - the transitional shape would then be like a logit function with the midpoint of 0.5x zoom sensitivity multiplier occurring at exactly half of the base FOV (i.e coefficient of 1 at the midpoint). This value probably makes the most sense, but I personally prefer a limit of 1.5, as seems the most appropriate for the zoom amounts we tend to use in games. As an example, this results in the highest zoom scope I used in BF4 having roughly 130% mdv, and the red dot sights having around 14% mdv when scaled from hipfire. The power could be raised to stay closer to focal length scale before approaching the monitor distance limit, but probably best to leave at or around 1-2. This is still just an arbitrary solution of course and I am not claiming it is objectively better than any established method, just an approach that very closely approximates my own preference formulaically - with pre-set limit / power of 2 I do believe it would be better for users as a "one click" option than the existing relative / USA with coefficient options.

The calculator does it for you. But for example, let's say you wanted to maintain the focal length scaling (i.e image velocity at screen centre). If you wanted to play 4:3 stretched at a native 16:9 horizontal FOV of 90, first find the FOV's at each aspect ratio (assuming the vertical portion is fixed with Hor+ scaling). We know the 16:9 horizontal FOV, so we can get the vertical FOV by doing 2atan(tan(horizontalFOV/2) * 9/16) * 180/pi, which is 58.72 We can get the new 4:3 horizontal FOV you are "stretching" by doing the reverse; 2atan(tan(verticalFOV/2) * 4/3) * 180/pi, which is 73.74 Focal length scaling is tan(fovA/2)/tan(fovB/2). So if we do tan(90*(pi/180)/2)/tan(73.74*(pi/180)/2) we get 1.333. In other words, your horizontal sens is now 1.333x faster than the vertical by "focal length" after the stretching. So you would just divide your horizontal sens by 1.333 (or multiply the 360 distance by 1.333) for the same focal length scaling on both axes (or do the opposite to the vertical to increase the sens on that axis instead). This will of course result in a different 360 distance for each axis, but the "tracking speed" at screen centre will now be the same for both. If you wanted to do a monitor distance instead, you would just plug in the monitor distance formula to the above process.

Depends what you mean by "sensitivity". You are changing the relationship between x and y within screen space, so the perceived sensitivity will change (if you judge it by monitor distance or focal length) on one axis vs the other, but the 360 distance will remain the same on both axes (unless a game actually ties sensitivity with resolution, which is extremely rare)

Yes, well kind of. The feeling you describe is just a result of having a smaller minimum angle reachable by the very slowest mouse movements. "Pixel ratio" describes the relationship between this minimum angle distance at screen centre in a 3D game world to the 2D pixel distance on the monitor at whatever resolution you have (therefore, the relationship is also a consequence of the configured FOV). As resolutions increase though, it becomes a completely moot point. If we were all playing on 8k screens, we would all be pixel skipping most likely, but it doesn't mean we wouldn't have sufficient angle granularity to aim accurately at targets in a game, which is the only important factor. I would say ever since resolutions went to even 1080p, it is no longer important in any practical sense. The configured DPI cannot change the minimum angle. It just describes what mouse distance sends a count of 1 to the operating system. 400 DPI means you have to move the mouse 1/400th of an inch to send a count of 1. Obviously, if you cram in more counts in less space with a higher DPI, it has the effect of increasing the output distance for any given mouse movement, but the actual sensitivity (that is, the ratio of output / input in the game) doesn't ever change.

Is it possible to get the measurements for scaling of the silenced pistol aiming added? (so I can set a DPI toggle)

The FOV defines how much angular distance (usually expressed as degrees rather than radians) of the 3D game world, are condescend into each pixel's worth of 2D distance on the monitor (whether you consider it in terms of each pixel, or across the entire screen). Since the resolution defines the size of those pixels within any given screen space, this is why not only the FOV changes the pixel ratio, but so does the resolution. The above assumes that the sensitivity (i.e the degrees per count) is not affected by the FOV which is most common. It is entirely possible for the sensitivity scaling of a particular game to maintain pixel ratio, at the expense of the 360 distance altering as the FOV is changed. In this instance, changing FOV would not affect the pixel ratio, but it would then affect the 360 distance instead.

Ok, so that's fixed the DPI, but the distance calculated in the output doesn't seem to be correct

I want to covert the same desktop speed to my new monitor, which has a higher pixel density so I will use a different display scaling (and also a custom resolution), but I cannot enter DPI to match the distance across the screen. https://www.mouse-sensitivity.com/?share=50d012f77fdf7686c74bf98d784da840

Games have different yaw values, so although you wouldn't need a different 360 distance if it's the same FOV, you still may need to know the value as games rarely expose their yaw value or sens formula to the user.

Did you decide against this in the end? I saw it didn't make the Jan update

It isn't required to be tested, because it's just simple math and the way a mouse works is already completely understood. I added it to a spreadsheet to show the timings of different DPIs until first data sent (which is NOT input latency, because a target distance is not defined for the input). Make a copy of the sheet and play around with the hand speed and DPI values and or/ system latency of other factors (such as GPU/ CPU / OS latency - which are also not static and vary between runs etc) and you will get the calculated delay until "screen flash" if you tested with the same methodology of the Battlenonsense or Optimum tech youtube channels. The only wiggle room on this is if the DPI reported by the mouse is not accurate. The reason the higher and higher DPI converges closer to the max value, is not because the effect changes, but because the larger total system latency of other factors becomes more and more dominant in the calculation. But in either case, none of these differences are meaningful when considering the delay to a target location, which is the only important factor for a pointing device. Of course, there will be sensors that perform differently on different DPI settings with either more or less drift, and a VERY low DPI mouse would obviously have visibly less accurate angle tracking due to fewer data points with which to define the angle of any direction. This is also to do with the firmware implementation of the mouse / sensor, as some may be even worse on higher DPI's. But this is also not really meaningful when it is tested with a 2D cursor, because cursors cannot sub-pixel increment, so any input is necessarily truncated to the nearest pixel position which doesn't happen in a 3D game. You would always get more visible "drift" with a cursor than what happens in a game.

That distance is just the radius. But to answer your question to find radius given central angle in degrees and chord length = c / sin(θ * pi/180/2) / 2

There's been some really high quality mouse review channels gain momentum like Badseed Tech et al with fantastic production values to their videos, but most are missing the ability to analyse mice on a technical level. There's a gap in the market for real-world factual test videos from someone with the understanding about how mouse input works that focusses on the objective, rather than subjective factors. hint hint

I'm not sure if DPI wizard still has access to that equipment, but ironically, that video was a bit ahead of it's time. The high-performance gaming mouse scene has grown significantly in both size and expected standards of quality since it was previously only a small esoteric bunch of nerds on overclock.net. I'm sure a lot more people would be interested in comparisons with more modern mice / firmware, even though the general consensus is they are all "good enough" these days.

Just to note this is not possible to do what you are suggesting. Any sort of FOV / zoom sensitivity scaling method describes a desired output velocity change at the crosshair between two different perspectives (i.e the FOV's), not input speeds. Any acceleration program takes a configurable calculated distance from your mouse input (which is usually sqrt(x^2+y^2) per poll) and sends that into a function to arrive at sensitivity value to multiply the passed-in (x,y) packet before it passes back out to the operating system. When your cursor / crosshair output velocity changes due to this acceleration, the relationship doesn’t change between the two FOV perspectives of a game due to the fundamental principle that they both increase velocity across the curve by the same ratio at all input speeds. Consider this extremely simple acceleration curve (and yes, I'm aware a linear line is never a "curve" but because the output velocity does curve it is still referred to as such) An input speed of 50 count/ms is 0.5x the sensitivity, at 200 counts/ms it is 0.75x the sensitivity, and at 300 counts ms it caps out to a static sensitivity of 1x. i.e if you were at 1600 DPI, the base of the curve would be effective 800DPI, the middle would be 1200DPI, and the cap would be 1600 DPI obviously. Therefore we can consider the accel function is simply dynamically scaling the DPI of the mouse in real time. If you use the calculator and change DPI for any scaling method, then it doesn't change the ratio between the source and the target game's (or desktop's) sensitivity no matter what the actual output values are. Focal length scaling at the base of this accel curve between any two perspectives, is also focal length scaled at the cap between the two perspectives, and also at every point in between, and this would always be true no matter what output value was configured by the "Jedi's Trick" system also, and also to/from a 2D / desktop environment

From the outset I would agree with Skwurul here that there is little value to this over any other arbitrary monitor distance "hack", and will likely produce results very similar to viewspeed v1, but in any case for the people that do want to use it - isn't the point of your system that you can define the maximum monitor distance to interp between that and the focal length scaled sensitivity? So let's say someone likes 50% mdh for high zooms, but 0% for low zooms, you could set 50%, so would be a lower mean than of 0-100%? Seems there is already a value box in the calculator to apply the max percentage into

It’s because you have changed monitor size, and you are converting to a distance defined on the smaller screen. if you want to ignore this, just set the same monitor size for both source and target.

There is no relevance to your resolution changing, since it doesn't affect the sensitivity. This is not a reason to change the monitor distance coefficient There is also no point in changing the coefficient to 0, to then scale the sens up per scope to 1.33 anyway. Just set the coefficient to 1.33 in the first place. Also, although it won't be responsible for much change, but you may as well set the FOV accurately, your MW2019 FOV converted to BF is 67.672748 degrees (use the config file).

Where did you lose it? Down the back of the sofa? "No" is the short version. We support this site because it's a great service and if we didn't the service wouldn't exist, so why should others pay for your calculations?

I see, yes, sensitivity matcher sends synthetic mouse events in user space, so these would not go through the Rawaccel driver. For all intents and purposes, you should imagine Rawaccel exists along the cable from your mouse to the PC.

As a sanity check, I just tried rawaccel in Ironsight and it works fine. My guess is your settings are quite subtle and / or the fact that Ironsight has incredibly low input latency and feels highly responsive compared to other games is making you feel like your settings are not applied, or perhaps you literally did not apply the settings in error. if you set the sens multiplier to something crazy like 0.01 or 10 and hit apply, you will see.

You can already do this via the discrepancy, if you change to advanced view, it shows you the DPI required for zero discrepancy for each aim Edit : just saw dpi wizards reply, although the calculation is extremely simple, it would be simpler to expose it to the user in that way with the multiplier

"For instance, I gave it a try on Ironsight and no matter how I set up the sens multiplier, the game still felt the same" Just to note this isn't true. There are no games that block it. Ironsight gets it's mouse input from the same place the desktop or any other game does, and since drivers like rawaccel / custom curve etc update the (x,y) mouse packet underneath the OS proper at kernel level and don't even require any user space process to apply the math, this would not be possible. This was not the case for interception based programs like Povohats, since they applied the math in a user space process before communicating with the interception driver, so a game's anti-cheat could block this user process from interacting with the driver. In order this to happen with rawaccel, Ironsight would have had to write a kernel-mode signed driver itself to read the (x,y) packet even before the rawinput queue, and also before any other filters in the low-level input stack, which for a game would be unheard of, expensive, unnecessary, and stupid.