Drimzi

It's a problem with the converter. 86.631971 should be getting rounded down to 86, and that would give you 0.9889534884 instead.

If they are the same aspect ratio, then the 32in monitor will have 105.96 fov inside the 24.5" region of the screen.

There is less degrees on the screen (lower degree/pixel), so if you continue to rotate the same degree/count then you will rotate more pixels. You have to reduce the degree/count to rotate the same degree/pixels, and end up with a longer distance to rotate 360 degrees. Degree/pixels only uses the middle pixels. If you know there is a total of 103 degrees horizontally (Overwatch), which is across 1920 pixels, then you can scale that down to find how many there is in 1 pixel. 2 * atan(1/1920 * tan(103/2 * pi/180)) * 180/pi = ~0.075032 If you drop to 30 degrees vertically (Overwatch Widowmaker), then you end up with less degree/pixel. 2 * atan(1/1080 * tan(30/2 * pi/180)) * 180/pi = ~0.02843 Since the game rotates a fixed amount of degrees/count for each unit of sensitivity, you will want to reduce the sensitivity when you scope in (by ~0.028/0.075) to keep the same pixel ratio. When scoped, you will have to rotate ~38% of the original amount to preserve the sensitivity of the mouse, but you will end up with the inconvenience of a larger distance to turn 360 degrees. (2 * atan(1/1080 * tan(30/2 * pi/180)) * 180/pi) / (2 * atan(1/1920 * tan(103/2 * pi/180)) * 180/pi) = ~0.378909

Monitor distance 0% is also for 2d to 3d. The distance to move the cursor 1 pixel is the same distance to turn 1 pixel. If you measure the fov in the 4 adjacent middle pixels, you will turn half that.

It's not that complicated. It's all about the physical scale of the image you see. If the scale changes, then sensitivity changes as well and you need to adjust the cm/360 to fix it. Treat the monitor as a window that you look through. Think of the resolution, fov, and monitor as an image resizer. If any of these change the physical size of the image, then you need to change your cm/360 by the same amount (monitor distance 0%). You will need to change the cm/360 in these cases because they will change physical size of the game: Different fov on the same monitor Same fov on different sized monitors Reducing resolution without upscaling Changing aspect ratio in a horizontal fov game Start with 103 fov at 1080p If you reduce the resolution to 720p without upscaling it, then you have shrank the physical size of the image by 66.67% of the original size. You will want to reduce your cm/360 to 66.66% of the original value as well. This is identical to zooming out 1.5x to ~124 fov. (2 * atan(3/2 * tan(103/2 * pi/180)) * 180/pi = ~124). This shows that the resolution can be used as an FOV slider if you want, you just don't get to see the extra fov since its black. Here we change the fov to 162 fov. It is a 5x zoom difference. It practically shrank the image to 20% of the original, so your cm/360 needs to shrink to 20% of the original value as well. Here is 103 fov resized to 20%, overlayed on the 162 fov. If this monitor was 5x larger than the above, then there would be no need to change the cm/360. The physical size of the 103 fov area in yellow would be identical to the monitor above. Since the monitor is basically a window that you are looking through, the 5x bigger window provides the extra fov. Here is the 162 fov image resized 500%. You can see that it's identical to 103 fov. If you reduce the resolution width to go from 16:9 to 4:3, and it only crops off the sides, then there is no change to the physical size of the image and no change to the sensitivity. If the game uses horizontal fov though, and it tries to keep the 103 on 1440px instead of 1920px, then there is a 75% scale difference (1440/1920). So your cm/360 needs to be 75% of the original value as well. This 75% reduction results in an equivalent fov of ~118 (2 * atan(1920/1440 * tan(103/2 * pi/180)) * 180/pi).

2304x1440 was stretched horizontally by 1.111x, so you need to use 3456x1600. 2304 is 90% of 2560. 90% of 3840 is 3456. 3840 / 3456 = 10/9.

Ignore the ingame fov slider. Your actual horizontal 4:3 fov is 70 * cl_fovscale. This converts cl_fovScale to ingame fov slider, no idea why its like this but it shows you can just ignore the ingame slider value as it is nonsense: (cl_fovScale * 70)/0.9625 - 70/0.9625 + 70

MDV 177.78% with 90% scale.

The pixel ratio is the ratio between the amount you turn per count and how much fov there is in the centre pixels. The camera has to zoom in or out to achieve a different fov in the same area (otherwise its just cropping/extending), so thats going to affect how much fov there is in the centre pixels. To keep the same ratio the amount you turn also has to scale with the amount the camera zooms.

The apex legends fov slider doesnt show any decimals. You can slide it to multiple steps and it will still say 104, so you won't end up with exactly 104 (1.4675 cl_fovScale). You have to look at your config to get your true fov. Your value of 1.471401 is ~104.2836. So what you want to do is set up apex legends first, then open its config file and then transfer those values (because these are your true values) to aim lab to train your aim, or mouse-sensitivity to convert to other games. Here I set game units to config file, put in your values, and then flipped it back to in-game units. You can see the fov is not exactly 104, and its matching mouse-sensitivity's 360 distance on the scope, which scales from fov. If the fov was wrong it would scale to the ADS incorrectly. You can also use this calculator to see how buggy apex is https://jscalc.io/embed/Q1gf45VCY4tmm2dq

If you change the profile in Aim Lab it will set the fov to the default fov of that game. Aim Lab's default fov is 70 (102.45 horizontal), thats why you are getting 102 after you change profiles. Why are you changing profiles anyway? Just set the profile to Apex Legends and put in the values. The Angle of View values will only show 2 decimals and the cm/360 will only show 3 decimals, but other than that it is the same.

The windows pointer speed only affects your cursor and there is nothing wrong with reducing it. So if you want 1600 DPI, then you need to reduce your game sensitivity for rotations, and windows pointer speed for cursor.

I think this should work: https://www.desmos.com/calculator/trk3nrmtkp It calculates the amount of distortion there would be at the location of the cursor at a specific fov. This will become the cursor speed multiplier, simulating the distortion of 3D. You would need to make a script that can continuously get the cursors xy position, calculate the distortion amount and then feed that into RawAccel somehow. Before going through the effort I think the whole thing is quite pointless if the desktop itself isn't distorted. If it's flat then there is no context to the cursor speed change. The cursor and desktop panning is already behaving correct to the desktop's fov of 0. You aren't looking at your arbitrarily chosen fov so the cursor speed changes will feel random. If you were able to distort the desktop after it has rendered then the cursor would get distorted anyway. Edit: I did a quick test to verify that the distortion calculation was correct as i wasnt sure. It says the distortion/speed multiplier will be 2 when moving the cursor to the top or bottom of the screen (y 0 or 1080) at 90 vertical fov. So in Aim Lab's creator studio I set the fov to 90 and placed a pillar that begins at the cursor and ends at the exact top of the screen. The sphere at the original crosshair position gets distorted vertically by a factor of 2 (from 34px to only half of the sphere being 34px). I then changed to 150 vertical fov. The pillar was now 145 pixels tall instead of 540, which makes sense since 540 / tan(150/2 *pi/180) = 144.69. I looked up 145 pixels and the sphere again stretched vertically by a factor of 2 (from ~9px to ~18px). In the calculator if you set 150 fov and cursor y to 540 +- 145, you get 2, so it appears that my calculations were correct after all.

I think you're going about it wrong. You're trying to make the cursor behave weird instead of just panning the screen or making the desktop 3D. The distances are affected in 3D because there is distortion and curvature, so it makes no sense for the cursor to behave weird when the 2D desktop has neither. It's already behaving how it is supposed to. If you decrease the FOV, which decreases the distortion and curvature, you will see that the mouse characteristics already start to resemble 2D more and more as you approach 0 FOV. At 1 FOV any conversion method in the calculator (Jedi's Trick has to be set to 1:1 resolution) will approximately match the speed and distance of the cursor. If you want to simulate 3D aiming then you have to move the screen instead of the cursor (e.g. panning in a photo viewer, or playing mcOsu's original fps mod, not fposu). If you want the speed of the desktop, with the distances reflecting the distortion on the screen, then you just convert using 0%. It doesn't matter what FOV you convert to/from, the cursor will increment 1 pixel for each count, and the camera will rotate 1 center pixel's worth of degrees. The circumference of the 3D projection (the red sphere in your diagram) divided by the distance to travel the projection's circumference (the cm/360, and the orange sphere in your diagram), will be identical to the distance the cursor travels divided by the distance the hand/mouse travels.

The math would use square 1:1 dimensions, not the diagonal dimensions. That would eliminate aspect ratio.