TheNoobPolice

There is going to be 4% difference (which isn't very much, borderline detectable IMO) in effective screen space sens if you sit at the exact same distance from both monitors. Usually though you instinctively sit closer to a smaller screen anyway to counter act this. To test this out, just set your sens 4% slower on the larger screen (at the expense of the same game world navigation familiarity). As an alternative, just create an unscaled custom resolution of 1843 x 1037 (i.e with black bars) on the 25" screen, then you can rule the monitor size out as causing the effect. The refresh rate difference is likely to have a more significant effect on feel, and / or a different rig hardware just having an overall higher / lower throughput latency or frame pacing. So not necessarily placebo as there might be real things affecting the feel, but the sensitivity aspect is unlikely to be the main difference.

Not really sure what you are asking. You can only change the FOV by the vertical because that’s what the game uses internally. If you use black bars for a 4:3 res to chop off a portion of the screen then you haven’t changed the FOV just because it now measures less horizontally (why would your crosshair behave differently if you took two pieces of paper and covered the sides of the screen?!) That said, whether “visual recoil” is affected at all by FOV depends entirely on the game, there would be nothing to stop a developer making a fixed 2D animation of the weapon barrel / crosshair not linked to FOV or the game world at all if they wished, although in most cases it probably is so it somewhat matches the weapon projectile and/or hitscan point. it’s quite simple to test though, set the FOV very low and look how much the sight bounces around within screen space , then set it high and check again. Doesn’t need to be very scientific to figure that out.

It doesn't matter whether you express an FOV as either the vertical or a horizontal measurement, but you need to compare apples to apples. If you enter a config FOV of 105 then that is a horizontal FOV of 120 at 4:3, since the game uses vertical FOV.

Around 5-10% update rate fluctuation is "normal" Windows behaviour and this is unavoidable, but much more than is usually some issue. Dodgy polling stability is most often caused by people messing with things they don't understand (such as running "latency tweaking" apps / configs, that usually just break stuff). I'd start with a clean install of Windows (on a separate partition if you wish to not commit just yet) and the bare minimum you need to see if the problem resolves without installing any complicating factors / drivers.

Well, there's a problem with that velocity graph you previously uploaded - whether it's caused by the mouse, the connection, driver software is not possible to say. Your "very cheap mouse" counts graph above doesn't show any discontinuities, although it clearly has some smoothing incidentally. Not necessarily a bad thing, depends on the implementation. The obvious test would be - do you get the same symptoms with the cheap mouse that you notice in game with you main mouse?

You’d want to view counts vs time and interval vs time. But looks like you’ve got packet loss based on the velocity graph. Time for a lot of troubleshooting by the looks of things.

Ensure you don't have any "latency tweaks" installed / applied to Windows, including USB overclocking or other nonsense. This often messes up device input. Use MouseTester to ensure your mouse is working correctly. If it is, this means you can completely rule out any hardware issue. Use that or the DPI analyser here to check your DPI is what your mouse software says it is. Ensure the game you are playing is a Raw Input game (Apex is) so there is no effect from your Windows mouse settings. Double check your sens and FOV in-game to ensure it is correct to what you want. Check you haven't changed monitor refresh rate or resolution - while this won't affect the sensitivity, it can affect the feel of the game. If all the above checks out, then I'm afraid it's you that's the factor

There is no solution to your request. "Instant" and "After" are emulations of an old, poorly designed system and should not even be options. "Gradual" is the only sensible choice, but even this is different between games - it can be "procedurally gradual" by FOV change per frame (so sens adjustment follows a sigmoid curve) or sometimes it's just "gradual over time" (linear sens adjustment). Even if you attempted a hacky fix, like scaling DPI by zoom transition time using a filter driver or script (which might trigger anti-cheats), you couldn't stop the game from doing its own scaling. This scaling is nearly impossible to reverse engineer unless you have access to the source code, which would still be an extremely inelegant solution. I'm afraid this just falls under "learn to play the new game," similar to adapting to changes in movement speed, camera pivot point, crosshair position, recoil/sway, and other factors that make targeting feel different in each game.

Just a word of caution, if you start messing about with scripting mouse movement there are an increasing number of modern FPS games that will find it suspicious behaviour. DPI Wizard can factor this risk into a business model, but it likely could be more devastating to yourself if a ban were to occur in a favourite multiplayer game. I wouldn't even recommend using Kovaak's sens matcher anymore in some games.

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;

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.