DPI Wizard

Unless you can extract the actual sensitivity formula from the game code (which is impossible for a lot of games), they need to be analyzed and formulas reverse-engineered. This needs to be done to perfection, and for the most part you need to script the movement. The process is basically analyzing the 360 distance for different sensitivities, and constructing two formulas based on this; one to convert sensitivity to movement, one for movement to sensitivity. I am considering an option to the calculator where the users can try out their own formula so they can suggest either changes or new games. I know there's a lot of math wizards on here, so it could be quite useful!

About 10:9.

I've removed it for now. I need to figure out what's causing the shift in sensitivity. If it's a random bug we need to wait for an update to fix it. I haven't checked the last update actually, it might already be fixed.

It might still be there, but it doesn't work (unless there's been an update the last few days).

Updated the calculator now, so try again without any workarounds I still need to check the scopes though, they are currently the same as before in the calculator.

Not possible I'm afraid, too much acceleration in that game.

Posting this here as well. A workaround for now: Enter a 16:9 resolution like 2560x1440 Enter your FOV when FOV Type Hdeg is selected Change FOV Type to Vdeg Change resolution to 21:9. What happens then is that the vertical FOV is preserved and the FOV for 21:9 is correct.

BTW, a workaround for now: Enter a 16:9 resolution like 2560x1440 Enter your FOV when FOV Type Hdeg is selected Change FOV Type to Vdeg Change resolution to 21:9. What happens then is that the vertical FOV is preserved and the FOV for 21:9 is correct.

It's locked to a ratio of the base FOV which is 80. I need to check if this base FOV changes with AR.

I see now what the problem is. The FOV value is locked to 16:9, the actual FOV of 21:9 is 118.75. I'll check what's needed to update it.

Ok, definitely seems like it. I'll analyse what happens with the ultrawide AR's.

Only the Hipfire (Advanced) calculation supports different m_yaw values. I will add this option in a more elegant way so it works both ways (calculate either m_yaw or sensitivity) and for all aims.

Ok, the issue is that the max value for Mouse ADS Sensitivity is 1, and this calculation actually result in a number above 1. Just barely though, probably around 1.02-1.03. So setting it to 1 is the best solution.

Can you post a screenshot of what you enter into the calculator?

Reversing it should always work if done correctly. R6 to CSGO hipfire: R6 ACOG to AWP: Reverse hipfire: Reverse AWP:

The resolution input is exactly the same as aspect ratio. The result of the conversion depends on what you are trying to achieve. If you want a constant 360 distance, then changing resolution (i.e. AR) does not change the sensitivity for games like CSGO. If you want a constant monitor distance however, it changes. A comprehensive guide is coming soon.

Games that have issues with acceleration or similar can not be fixed with an external program. Four typical issues I run into with games are: When the sensitivity get low enough, single counts are simply ignored. Very easy to notice with scripts, and reproducible with low DPI and slow movement which result in no or jagged movement in the game. Inconsistent distance moved with single counts. This is the worst one probably, Arma 3 comes to mind that have (or at least had) this issue. When moving back and forth 1 count you obviously expect the crosshair to end up at the same place, but several games have issues with this. When a single count is not registered properly there's something fundamentally wrong with the game. This is not how acceleration typically works either, that's the next issue. Acceleration, meaning the distance moved varies depending on either packet size, report rate or a combination. Packet size is when sending 100x1 counts does not result in the same movement as 1x100 counts. Report rate is when 100 counts in 100 ms does not move the same as 100 counts in 1000 ms. "Negative" acceleration, which is basically packets dropped. None of these issues can be fixed with any universal external program, as the issue is what the game engine does with the information from the mouse, not what information it gets.

Chinese translation and others are coming this summer.

I'll take a look this weekend. It's been a few updates since I added it.

When you measure FOV in 3rd person you need to measure with an object extremely far away to get an accurate measurement. Objects close to you will not give the correct result since the camera pivots around your character.

Fortnite removed the sensitivity from the config file, so it no longer works. You have to set it in-game unfortunately.

FOV affects the 360 distance directly on some games (it is shown in the game info). I'll do some more work on Deep Rock, as I might have stumbled upon a bug.

Sounds like exactly the 25% change I was experiencing. I need to figure out what happened there. Changed it now to the other value, try again.

It's using Monitor Distance 75% (when you switch between simple and advanced the conversion method is not changed). The issue is that Simple Mode uses default values for sens 2 and multiplier 1, so it will not work with calculations such as iron sight or ACOG for R6 config file. You have to use either Advanced Mode or in-game for this to work. In-game (meaning MouseSensitivityMultiplierUnit and XFactorAiming must be set to 0.02): Advanced: