DPI Wizard

Full version updated!

I haven't really noticed this, but I pretty much only use Linux through VMware and Teamviewer or RDP etc, and not for gaming. As you say it shouldn't be an issue between different OS, as the base should always be X counts equals X pixels movement. Add acceleration and a multiplier/dividend on top of that, but the base should always be available as an option. I'll look into it if I find the time

Yes

Updated now for the in-game calculation. FOV scaling seems like before, but as mentioned earlier the FOV is not very accurate in this game, so expect some small variations.

Great, will update it!

UT4 had a bug in the formula, fixed now! Thanks for the heads up Regarding preserving FOV, I agree that it would be nice to do this between games. But it should be a check-box like you suggest, as it might cause confusion. And it must be clear when the FOV is reset to default because the preserved FOV is out of range, or FOV is not possible to adjust for the game. I think adding a selection to automatically convert FOV (if possible) is what I'll go with for the next update.

Personally I like the BF4/BF1 implementation the best. It allows for individual settings for (almost) all zoom levels, as well as a base setting that should feel good for most people. The tweaking options are plentiful, and the range of the settings are enormous. But since these settings are unique for these games (including to some degree Hardline and Battlefront), it's not a very universal standard to implement. I would say without a doubt the Source engine equivalent sensitivity is the most recognized and universal implementation, with standard Unreal Engine 3 at a good second place.

The monitor size is just used to calculate the ratio for now, meaning the relation between how far you move your mouse and how far the cross hair moves: 1 inch mouse movement = 9.413 inches crosshair movement Since the 360 distance will vary when using monitor distance, this calculation is used as a baseline instead. But in the actual calculation "counts" are used instead of inches or cm, so the monitor size and resolution is used to convert it to a meaningful unit. It is not used for the actual sensitivity calculation.

"Match at" is a percentage of half your FOV. To put it simple, if your 360 distance is 10 inches, actual FOV is 90 degrees and match at is 100%, the calculator will make a 1.25 inch mouse movement match a 45 degree in-game movement, which means moving from the center of the monitor to the edge.

It's not really a bug, just a consequence of the fact that changing the FOV does not change the 360 distance.

It is only 0% at FOV 70, higher FOV results in higher % match at. At FOV 90 it is approx. 45% match instead for all zooms, so it's unfortunately impossible to match them all at 0% with FOV 90.

The way the desktop conversion works now is a little different than that. What it does is matching the movement from the middle of the monitor on your desktop to the percentage you choose in the "match at" box (0% being exactly under the cursor, 100% being the edge of the monitor), to the same movement as moving the crosshair to this position in a game (where 100% is moving to what you see on the edge of your monitor), or vice-versa. In other words the same distance on your monitor. Matching a full 360 to edge-to-edge movement would probably not feel right. So when you convert from Overwatch to Desktop (which I assume it is you're doing), it's telling you what to set the DPI to in Windows to best match this movement.

Great!

By the way, this is why it doesn't work that way now: What you want is this: But what you actually get is this: I'll work on a fix for this though.

When you use the simple calculation for Siege, you only calculate the sensitivity you have access to in-game, and it assumes that all the multipliers are at the default setting (0.02). Since this setting only have 100 steps, it is not very useful for fine tuning. This is why you get the discrepancy, it is the closes it can get with this value alone. If you use the advanced calculation however, it is very accurate, as this calculation uses the multiplier too. So what you need to do when using the advanced calculation is fill in the value it asks for. This value (for hipfire) is your already configured MouseYawSensitivity. It doesn't really matter you have set it too. The output will be what you should set the multiplier too to get the desired sensitivity. The reason you have to enter the configured MouseYawSensitivity is that the sensitivity is a product of both MouseYawSensitivity and MouseSensitivityMultiplierUnit. Tell me if you have any trouble!

Some Paypal transfers take a few days to clear, but I've manually approved it

It has some issues with negative acceleration, but is now added with that caveat.

Just added, but note that there is quite a lot of negative acceleration at lower sensitivity settings. View full update

Added config file calculations, makes for a much more precise setting!

Thank you, updated

A new advanced mode was added recently for CSGO, which requires you to also enter the m_yaw value (default 0.022). The CSGO aim defaulted to this selection, but I've changed it now so it defaults to the regular hipfire instead.

I'm on the same version as you here. Do you run any extensions like script blockers etc? Or just a clean Chrome? Are you able to select games?