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.