TheNoobPolice

Whilst the game sens at lowest value may seem the most obvious, it is not that unusual for sens values to be a bit broken at very lowest values in some games and these tend to work best at default values. However, default values can often be undesirable due to having a pixel ratio greater than 1 on very high resolution displays (which although is kind of moot really, it’s the sort of thing people still want to avoid). So I think the best option would just be for the calculator to have an advanced option to solve for the multiplier when the user inputs both target game sens and mouse DPI. This leaves it in the hands of the user what game sens value to pick in the target game, (based on the minimum | default | maximum values shown in the info section), because hardcoding the minimum value is probably not the best for all circumstances.

I think what you really are effectively asking, is for the user to be able to enter the target game sensitivity (which in the above example would be the minimum of "1"), and then solve for the target DPI instead (and therefore, if with mouse DPI entered, output a scaling multiplier for said DPI). Because whichever way around it is, there needs to be 2 of the variables input to solve for the 3rd output - the calculator can't be solving for the game sensitivity based off a DPI input field, whilst also outputting a multiplier which effectively scales DPI because it's then a circular dependency. Or...perhaps, it could be a mode where the calculator automatically inputs the minimum (or default?) sens for the game, and then outputs the multiplier required? So the user inputs mouse DPI, the calculator automatically inputs minimum available in-game sens, and therefore can solve for DPI scaler? I think that could be useful in some circumstances, but I also feel that the way you are going about this in general is probably fairly unique to yourself, because changing a filter driver DPI scaler instead of the game sens has the rather conspicuous side effect of also changing your desktop cursor every time you want to play a new game.

How would the calculator know what your Raw Accel sens multiplier is? Are you saying you want a filter driver DPI scaler field so you don't have to do the math?

Raw Accel scales your DPI effectively, so if you're still entering your mouse DPI in the calculator when scaling it by Raw Accel, you're not really doing it right. You should enter the output DPI.

It's fairly easy to do a "full pitch/yaw time to 360", and then calculate zoom scaling methods from the same barometer. This is how the BF USA worked on sticks. The real issue is that it's relatively meaningless. A joystick is basically "servo aim" - you move the stick to a position and the system continually aims for you effectively. You are not "aiming" yourself as far as a distance. This means that for every position on the stick, you have gotten to that position through an arbitrary small amount of time moving through lower positions, meaning the output for each stick position over time is always different, including full yaw from any starting position != full yaw (which is always). It is humanly impossible to make the exact same motion a second time. This is true regardless of whether the game adds additional stick acceleration curves for either physical stick accel or stick position. In other words, sticks always have inherent negative acceleration as you move them due to their physical properties. This is before you start with the response curve which is rarely linear by default, even if a game does not add stick acceleration. It may not matter to those wanting the conversion of course as the perception of at least "something" matched may be satisfactory, but the situations where you could take a setting from game A, move it to game B at the same FOV and it be "the same" in any meaningful way (and by meaningful, I mean "any arbitrary stick movement produces the same angle displacement over time in the game world at a given FOV") would likely only exist a handful of times within the same game franchise.

Well let's put it this way, if the symptom does indeed have the same cause as what yours is, and is indeed the same symptom, then they all absolutely don't know how mice work, because that's what happens well within normal spec and it's not up for debate. So we then have to presume they are working to fix a different issue that just has similar sounding symptoms, and / or an separate issue that simply exacerbates the very normal symptoms that you have. I don't have the inclination to read through all their posts, because I already know what your issue is. It's extremely clear and understood that you have expected behaviour, you can see in this test I shared before, that all mice drift, and usually in the same pattern with the same type of motions, even when moved in a totally consistent way by a machine (which would always produce less drift than a human hand). The difference is usually how much smoothing is applied internally or the accuracy of the sensor / implementation to begin with, along with surface differences that affect tracking performance slightly, but it never goes away entirely. The idea that all these mice from different brands, all made by different engineers in different years, all just happen to have the same "glaring bug", and they all just happened to not notice it to fix it? And you claim what I said was far fetched?! In any case, I've tried on multiple occasions now to reassure you but you don't seem interested in that. Anyone can see by moving their mouse around on the pad within screen space, and then moving the mouse back to the exact same starting position without it leaving the pad, that the cursor will now be in a different pixel on the desktop than in it's starting location. This is really nothing special or unusual I'm afraid. In any case, I've exhausted my interest on this particular topic, so I'll leave you to it.

Who knows? Maybe they just all don't know how mice work or maybe it's a slightly different issue they had. In any case, as far as your issue that you highlight and demonstrate - it's very clear what it is, it's totally understood, and totally expected.

I think you are confusing it with the reverse icon on the calculator which swaps target game for source game. The reverse button is used to find a conversion method via existing sensitivities, instead of what the calculator usually does; which is to find sensitivities via a selected conversion method.

I don't think anyone said it's intended behaviour, it's a consequence of current optical sensor technology that is unavoidable - working as expected != working as intended. I'm quite sure the boffins at Pixart don't intend to make a mouse sensor that drifts, it's just the best they can do.

I'd suggest you just try vertical, since it's aspect ratio agnostic

I don’t really understand what you are getting at here. The work IS already done for you on this website - that’s what the calculator is! I think in general people have the wrong impression of so-called AI (in reality, pattern matching) models that exist at the moment. It’s just linear algebra. It can’t help you with your human preferences. Good GPT prompt: “Give me the formula for so and so’s theorem in standard math notation” Bad GPT prompt: “What colour should I paint my living room?” GPT is great as a resource for facts or to pull together knowledge which has been typed before “somewhere”, but it can’t decide what kind sensitivity conversion you will prefer in a given game.

It's actually nothing to do with the DPI of the mouse. It's only defined by the game's sensitivity, the FOV and the screen resolution.

This is far less trivial than you might think - you’re looking at a decent level of understanding of computer sciences in general, coding knowledge / ability to develop accurate testing methods, and a good grasp of algebra, trigonometry and a pinch of calculus thrown in. There’s a reason this site/service is successful and the only one at the quality level it is at - DPI Wizards don’t grow on trees

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;