Kilroy

It's unused for now, but will probably be used should they introduce a more powerful scope than 10x.

Viewspeed v2
 
DNAMTE has come up with another solution for converting sensitivity to different field of views. This time it is independent of the aspect ratio, which is a flaw with viewspeed v1. The aim of this solution is to make the different field of views behave the same visually when moving the mouse, solving any perceptual issues such as feeling like it is slowing down or speeding up. This makes this method especially useful for zoom/ads sensitivities.
 
The sensitivity scaling is done using two ratios, the circle ratio and the chord ratio.

 
DNAMTE is unsure on how to do the math for it, so I will do it. In the picture above, he did 90 degrees and 45 degrees for the angle of view, and found a chord ratio of 2.41 and a circle ratio of 1.3.
circle ratio / chord ratio The chord ratio can be found using:
tan(y * pi/360) / tan(x * pi/360) Where the variables are the degrees. If we substitute x for 45, and y for 90, we end up with a ratio of 2.41 as shown in the image above.
Scaling the sensitivity by the chord ratio alone would be equal to scaling the sensitivity by the zoom amount.
 
The circle ratio can be found using:
cos(x * pi/360) / cos(y * pi/360) If we substitute x for 45, and y for 90, we end up with a ratio of 1.3 as shown in the image above.
 
Put these two together, and you simply get the sin ratio.
(cos(x * pi/360) / cos(y * pi/360)) / (tan(y * pi/360) / tan(x * pi/360)) = sin(x * pi/360) / sin(y * pi/360)  
When substituting the variables with the angles, you want to use the vertical / horizontal angle for the 1:1 aspect ratio.
 
With this additional option of converting sensitivities, you end up with the options of converting using the tan ratio (mm 0%), sin ratio (viewspeed v2), or matching a screen-space distance using monitor distance match.
 
Recommendations:
Use tan ratio (0%) or 360 distance match for converting hipfire. Use tan ratio (0%) or sin ratio (viewspeed) for converting zoom/ads.

In the equation in the first post, replace d with the result of (resolution/mouse dpi), and replace theta with your game's actual fov. The formula'll give you the cm/360 or inch/360 you should be using at that fov, if this equation is to be trusted in doing what it's supposed to do. Go into the calculator and put in that result to get the sensitivity you should be using, in that game.
I just tested it out, and I think it feels better, but I don't know if that's just placebo. To be honest, we need a way to measure and quantify that perception of speed, to really put this to rest. If that even makes any sense.

In the equation in the first post, replace d with the result of (resolution/mouse dpi), and replace theta with your game's actual fov. The formula'll give you the cm/360 or inch/360 you should be using at that fov, if this equation is to be trusted in doing what it's supposed to do. Go into the calculator and put in that result to get the sensitivity you should be using, in that game.
I just tested it out, and I think it feels better, but I don't know if that's just placebo. To be honest, we need a way to measure and quantify that perception of speed, to really put this to rest. If that even makes any sense.

All the maths of the Viewspeed function are done now (2D-3D, 3D-3D and 3D-2D).
I need to add some error checking, fix the output and adjust some scripts. Should be done at least by the end of the weekend!
 
All tough most relevant information is posted in this topic, I will also make a summary of it explaining the method and how it works.

Putting DNAMTE's ideas into math.
360/hfov * desktop distance * chord /arc = 360° distance We are playing CS:GO which has 106.26 horizontal FOV, on a 2560x1440 monitor, with a 400 DPI mouse. We can find our horizontal desktop distance by doing the following:
Resolution Width / DPI * 2.54 = desktop distance (cm) 2560 / 400 * 2.54 = 16.256 cm The arc we can calculate by doing the following:
chord + chord * (fovradians - 2 sin(fovradians/2))/(2 sin(fovradians/2)) Our FOV in radians can be calculated like so:
hfov * π / 180 = fov (radians) 106.26 * π / 180 = 1.85459... radians The full arc calculation is:
2560 + 2560 * (1.85459 - 2 sin(1.85459/2))/(2 sin(1.85459/2)) = 2967.34 So we have a chord distance of 2560 and an arc distance of 2967. When the game is 2967 pixels wide, you can see why it is distorted to fit into 2560 pixels. Now we have our two distances we can convert it to a 360° distance and find our perfect sensitivity for our given FOV.
360/hfov * desktop distance * chord /arc = 360° distance 360/106.26 * 16.256 * 2560/2967.34 = 47.51372 cm This concludes that with 2560x1440 and a 400 DPI mouse, the perfect sensitivity to match the desktop pointer speed will be 47.51372 cm 360° distance. This is accomplished using 2.186936 sensitivity, equal to 875 eDPI as a reference point when comparing sensitivities to other players.

The full formula without using rounding would be like so:
360/106.26 (2560/400×2.54)×2560/(2560 + 2560×(106.26×π/180 - 2 sin(1/2 (106.26×π/180)))/(2 sin(1/2 (106.26×π/180)))) = 47.5137... Simplified down to:
(4 π z sin(x/2))/x^2 where x = fov radians and z = desktop distance (4 π (2560/400×2.54) sin(1/2 (106.26×π/180)))/(106.26×π/180)^2 = 47.5137...  

Hey, here's a picture that might explain the maths behind what I'm talking about:
http://i.imgur.com/LiDfxls.png
 

 
Basically, the equation of a circle is (x-h)^2 + (y-k)^2 = r^2, so if we simplify the equation in terms of y we can integrate it and find the average value of the equation. But since this is only for a single FOV, we need to create a list of average values for a given range of FOVs and then find the average of all those averages and that will give us the Monitor distance we are looking for. I know this is messy and I should use a triple integral, but I don't know how to do them (can't be bothered to learn how... but creating a list of single integrals and then finding the average of them is precise enough). The given FOV range is something you would be able to change to your liking. Just check this spreadsheet out and you'll find that you can have a FOV range of 172, 150, 126 or 96 (I didn't include anything lower than 96 as most games have at least 90 FOV): https://docs.google.com/spreadsheets/d/1INqG-_fvx2BrsknyrPuPiNkx5UBoMGi3ULs_oCQcaBs/pubhtml
 
As you can see, the calculated monitor distances you can choose from are 30%, 25%, 20% or 15%. Since the mouse sensitivity calculator only goes up in increments of 5 and doesn't have decimals, you can only pick one of these 4 monitor distances. I personally chose 25%. I don't really intend to use anything higher than Quake Live's FOV of 130 so 150 FOV is more than enough for me. If I was using a 21:9 monitor and I wanted to go higher than I might consider using 30%. So depending on your circumstances, choose either 25% or 30%.

IMO the perfect match is with cursor speed rather than monitor distance. Afterall that is essentialy what you are learning, not a distance on a monitor. Your familiarising yourself with the speed your cursor moves from point to point. The better you judge this the faster the movement, the more 'snappy' you can become.
 
Matching cursor speed is also much easier and consistent across ALL FOV or even 2D-3D. If you match your 2D cursor speed to the rotational speed in 3D then the 'feel', the 'speed' of your cursor is the same. You can match this to any FOV and cursor speed will always feel identical.
 
To give a brief example of this:
Here we have a monitor distance (in red) and the arc Field of View of 180 degrees in black. (highlighting larger FOV's, the less accurate monitor matching becomes. This is also true when comparing two FOV's, the greater the difference the worse they match)
 
For simplicity, the monitor distance (chord length) is 2 therefore the Arc length is equal to 3.142... A 57% increase in length. This means when matched at 100% monitor distance the 3D 'cursor' must move at 57% greater speed than the 2D cursor.
 
The inaccuracies 'reduce' as you eventually lower FOV as close to zero as possible. Essentially reducing the sample size to something so small the difference appears negligible. IMO not ideal.
 
Making the 100% monitor match value 57% less however places cursor speed identical in both planes... 2D & 3D?
 
 
NOTE: obviously the percent changes with each FOV.
For example 106.26FOV (90 4:3) is 15.8% which equates to roughly 65% on the implemented monitor match calculator.