Drimzi

Sticking to 0% would be ideal, but it can feel slow in ads/zoom, relative to hipfire. For one, you change the scale due to zooming, which means physical mouse input is going to change proportionately with the change in image scale. If your characters movement speed stayed the same after zooming, then you will be moving the mouse further and faster to counter it as well. You can amplify the sensitivity if you want to make it easier to aim. Go by feel before trying to calculate a perfect value.

You only have to set 114 if you use 114+ in bo3, and no you dont need to use an ads multiplier, legacy is the exact same ads sens scaling as bo3

To best match BO3: Set BO4 to 114 FOV to roughly match BO3 at 114+ (the fov doesn't increase past 114.6 in bo3 due to bug, which translates to 113.86 fov due to another bug lol) Convert using Monitor Distance Match 0% Leave ADS sensitivity on Legacy or Relative with 0 coefficient Leave ADS FOV on independent

This bug is still there. From 114.6 onwards, it is stuck at Actual HFOV: 113.86 degrees

The issue is thinking of it in terms of 2D, or basically the whole idea of matching to pixels. It's only going to work in pure horizontal or vertical movement because 3D !== 2D. Monitor Distance Match works by matching distance to degrees, not pixels. So if you did a conversion, and have 90 degrees angle of view, horizontally, in one case, and 60 degrees in another, the distance to rotate 45 degrees (90/2) will be the same distance to rotate 30 degrees (60/2). This is reasonable. Now when you try and put this into a 2D perspective, like saying it is matching to a ring of pixels an equal distance away from the crosshair, it falls apart. What's actually happening in each method: Viewspeed - Vertical : An aperture dependent conversion, scaling the sensitivity by the change in Vertical Chord Length. Viewspeed - Horizontal: An aperture dependent conversion, scaling the sensitivity by the change in Horizontal Arc Length, as well as the difference between Horizontal Arc and Chord Lengths. Monitor Distance Match - Vertical : An aperture dependent conversion, scaling the sensitivity by the change in Vertical Arc Length, using a user defined aperture size. Monitor Distance Match - Horizontal: An aperture dependent conversion, scaling the sensitivity by the change in Horizontal Arc Length, using a user defined aperture size. Monitor Distance Match - 0%: An aperture independent conversion, scaling the sensitivity by the change in Throw Length (zoom). The Viewspeed methods don't just change the measurement axis. They are both completely different methods. Viewspeed - Vertical should be using 1:1 measurements rather than Vertical. Horizontal is an older idea that was similar to Monitor Distance Match - Horizontal, but scaled by the difference in Horizontal Arc and Chord lengths. All methods except for 0% depend on the aperture, which is the hole you are viewing the game world through. The hole being your monitor. Since you get different results for using different measurements, you end up with so many different methods. The only consistent method is the one that ignores the aperture, which is 0%. You can use vertical, horizontal, diagonal measurements, it doesn't matter, the result is the same.

Try 0% conversion for everything. Override it with a sensitivity that is somewhere between 0% monitor match and Viewspeed for ADS/Zoom.

No worries. As long as your sensitivity is behaving according to expected preference, there's not really any downsides. It's the performance that matters.

What your doing is completely arbitrary, but I can make it even easier for you. Convert using Viewspeed - Vertical. However, halve your CPI for the input game, and use your actual CPI in the output game. You will get the sensitivity value that you are seeking.

My method does what you are describing. If you keep the same viewspeed, your mouse input does not change relatively before and after the ADS transition. If you don't keep the viewspeed, your mouse input changes proportionately with the change in image, which is no change in sensitivity at all. Equal 360° distance at different FOV does not equal no change in sensitivity.

Ideally you would keep the distance to rotate a full revolution the same, but it's currently not practical. When you zoom in a game, the monitor doesn't move forward and back, all it does is reduce the angle of view. Since the monitor doesn't grow or shrink to change the angle of view, the game zooms. If the monitor did move forward and back, or if a change in FOV resulted in the monitor physically growing/shrinking, you could keep the 360° distance and it wouldn't feel too fast or too slow. Since the monitor size is constant, changing the angle of view results in a change in zoom. It's the only way to do it. You can think of the monitor as a window to the game world. The size of the window is the aperture, the pixels is like a mesh screen-door. You don't base the sensitivity on any properties of the window itself, but you base the sensitivity on the change of the game world. When you change the FOV of a game, you change the zoom (focal length when you include physical measurements). Scaling the sensitivity by the tangent (0% monitor distance match) will scale the sensitivity by the change in zoom. Changing the physical size of the window (monitor size), you also scale the sensitivity as it is a change in focal length. Not directly using 0% monitor distance match, since that is only based on zoom, but by changing the physical sensitivity (mouse CPI) in addition to 0% monitor distance match. The fault with 0% monitor distance match is when you change FOV on the fly, like when you aim down sights or use a scope. Your comparing a zoomed state to a non zoomed state, where the scale of everything is different. The sensitivity will feel different relative to each other, as you have to scale your mouse input proportionately with the change in scale. The sensitivity would only feel identical if you moved the character forward/back to counter the zoom, and compare with identical scale. As seen in this video. So 0% is the way to go if you want to convert Hipfire. You can also convert with 360° distance if that is a preference that you want to keep. If you want to keep the mouse input relatively the same when you change FOV on the fly, that's where Viewspeed comes in handy. It scales based on the chord length. This is the method that you would want to use instead of Monitor Distance Match, if you wanted the 'window to the game world' to influence the sensitivity. Your mouse input will not scale proportionately with the zoom. Instead, you wouldn't scale it at all. The result will be completely wrong for Hipfire, but when comparing sensitivity relatively before and after a change in FOV, it becomes useful. Subconsciously, you would want to scale your mouse input according to the change in image, so you would probably scale your mouse input to some degree, how half-assed of an attempt at doing so, depends on the person. This makes Viewspeed feel too fast. I actually just made a solution to this in another post, where you specify how much you need to scale your input by, 0 proportionately with the change in image (zoom), or none at all (viewspeed). You can't increase the FOV, but you can change the zoom. Just reduce the resolution, with black bars, to change the aperture (the physical size of the window to the game world). Scale the sensitivity by the change in aperture size. You can make it the same as a higher FOV game, but the extra FOV is just blackness instead. With this method, you can make every game have an identical focal length, despite having different angle of view. This is the only way to keep 360° distance identical in every game, using different FOV, and have it feel the exact same.

Just note that this isn't true. It will only match perfectly for the pure horizontal or vertical points. The reason is because the aim will curve with the pitch as soon as you deviate away from the equator. Any movement that isn't pure yaw/horizontal, is a change in pitch. Even pure yaw movement is circumstantial. As an extreme case, look straight up or down, your aim will be so curved you will be a spinning ballerina, yaw movement will not reach the point on the ring. Diagonal movement will not perfectly match a point on the ring either. The only movement that will reach a point on the ring would be vertical movement. 2D is flat, so the cursor always moves in a predictable way. 3D isn't, only pure vertical movement is always moving the shortest path and will match the point on the ring. Horizontal is circumstantial, requires a pretty neutral pitch. Diagonal will not match any point. This is a reason why I think monitor 'distance matching' isn't helpful in any meaningful way. The result is just an arbitrary change in sensitivity that may happen to be close to preference.

If you wanted to scale the viewspeed formula... Instead of viewspeed scaling the sensitivity/circumference (not the sensitivity value since its not always linear) by: sin(fovB * pi/360)/sin(fovA * pi/360) You would want to scale both FOVs by a multiplier. 1 would equal viewspeed, 0 would equal tangent scaling. You can scale the fovs like this: (360 arctan(multiplier * tan(fov * pi/360)))/pi Here is a simple calculator I whipped up for you. Mult = Multiplier for viewspeed. e.g. 0.5 = 50% FovA = Input game's fov AspectA = Input game's fov aspect ratio/measurement (1 = vertical, 4/3 = horizontal 4:3, 16/9 = horizontal 16:9, etc) DistA = Input game's circumference (distance to rotate 360 degrees) FovB = Output game's fov AspectB = Output game's fov aspect ratio/measurement DistB = Output game's circumference Get the DistB value. Use mouse-sensitivity.com's calculator in 'Convert Distance' mode, put in the distance, and it will tell you the sensitivity value.

I wonder if they will fine tune the sens value to be identical to Overwatch. Last beta it was less than 1% off.

Pretty sure the error % will only be based on pure horizontal or vertical movement (scripted movement). Error % for diagonal movement to any other point on the ring will be too complex to work out, and due to only vertical movement following the geodesic, I don't think you even land on the ring with the correct distance moved anyway. Diagonal movement will behave differently for every FOV.

Remember that at the end of the day, it's all preference. 0% converts the sensitivity. Other methods generate a sensitivity for a specific purpose. 360 is useful for maintaining mobility, but i would never recommend it for zoom/ads. The reason why: If you zoomed in, the monitor would have to move away from you. Since the monitors location is fixed, 360 conversion wont work. If you changed the fov, the monitor would have to expand or shrink. Since the monitors size is fixed, you cant manipulate fov without affecting zoom. The monitor is the aperture, and the only true conversion is one based on the focal length rather than the fov itself. 0% scales based on the focal length, assuming the aperture is constant. It will give the correct conversion considering you dont convert to other apertures/monitor sizes.

0% is a direct conversion. It's the baseline, results in no change in sensitivity (not talking about the game sensitivity value here). You have to scale your mouse input proportionately with the change in image. Since ADS is something you activate, and can zoom any amount within an instant, it can be preferable to amplify the sensitivity. Viewspeed will make it feel the same before/after the zoom without changing mouse movement, so it is pretty much the max amplification you would want. Higher than this and it will feel like you are decreasing your hand movement after the ADS transition. Viewspeed sounds good, but the change in image will have you wanting to scale your input properly to some degree, and this conflict will result in bad aim. If you do want any amplification, just go by feel as that will find your preference. No conversion necessary, as it is an arbitrary change in sensitivity. Monitor distance match IMO is a useless conversion that results in a different arbitrary amplification for every FOV. A better idea would be to scale 0%, and then amplify it by a arbitrary amount. So every ADS in every game is going to be x % faster than the change in image. A constant amplification, triggered by the press of a button. You could even go slower than 0% if you wanted to, to reduce the sensitivity for precision. Since ADS is something you willingly trigger, you can get away with multiple sensitivities as the 'muscle memory' can be linked with that specific weapon. Just means you will have a lot of different 'muscle memory'. My recommendation, do 0% conversion for everything. If it is uncomfortable scaling your mouse input by the change in image, which can be a big difference in an instant (like if you do like a 4x zoom, that's a 4x difference in mouse movement within a few milliseconds), then go by feel. Check how much you amplified the sensitivity by. Use that as a coefficient over 0% whenever you convert to ADS. My 2¢.

Use 0% to correctly convert from hipfire to ads. If the zoom transition is uncomfortable, try viewspeed or just go by feel.

If your debating whether to use viewspeed or 360 distance: Use 0% to correctly convert sensitivity to other fov. This is the baseline sens. Only use 360 distance for hipfire to keep muscle memory related to movement and 180 flicks. Only use viewspeed or monitor distance match for zoom/ads. Basically anything that changes fov instantly on the fly.

In regards to this post: https://www.mouse-sensitivity.com/forum/topic/3340-monitor-distance-5625-or-75-which-one-can-give-better-match/?do=findComment&comment=13211 0% is actually better for 2D conversion. 1. The rotation increment is equal to angle being displayed by the exact center pixel. https://www.mouse-sensitivity.com/forum/topic/3340-monitor-distance-5625-or-75-which-one-can-give-better-match/?do=findComment&comment=13239 2. At 1080p and 90 (1:1) FOV, it will be 540 counts to rotate 1 radian. It matches the radius of the desktop, i.e. 540px, to 1 radian of rotation. 1920x1080, 90 FOV = 0.1061...° increment 1 radian = 57.2958...° 57.2958 / 0.1061 = 540 3. The ratio between the distance to rotate 1 radian, and the circumference is 2pi. 360 degrees is equal to 2pi radians. CPI = 400 Increment = 0.1061° Circumference = 2.54 * 360 / (0.1061 * 400) = 21.5... cm Distance to rotate 1 radian = 2.54 * 540/400 = 3.429... cm Ratio between circumference and 1 radian = 21.5 / 3.429 = 2pi 4. If you make the mouse and cursor have an exact 1:1 physical relation, i.e. a control-display gain of 1.00, then the ratio between the focal length and the circumference at any fov is also 2pi. 1920x1080, 24.5", 90 FOV 1:1 ratio = (sqrt(1920^2 + 1080^2))/24.5 = 89.9... CPI Focal length = 2.54 * ((24.5 / sqrt(1920^2 + 1080^2)) * (1080/2)) / tan(90 * pi/360) = 15.25... cm Circumference = 2.54 * 360 / (0.1061 * 89.9) = 95.87... cm Ratio between circumference and focal length = 95.87 / 15.25 = 2pi Again at 50 FOV Focal length = 2.54 * ((24.5 / sqrt(1920^2 + 1080^2)) * (1080/2)) / tan(50 * pi/360) = 32.7... cm Circumference = 2.54 * 360 / (0.0495 * 89.9) = 205.5... cm Ratio between circumference and focal length = 205.5 / 32.7 = 2pi

CSGO should be 90 FOV. The correct conversion would be 5.50 OW.

Viewspeed v2 is suppose to use the shortest measurement. Not vertical in particular. It should be horizontal in portrait orientation rather than landscape. The multiplier is: sin(SquareDegrees * pi/360) Viewspeed v1 uses horizontal degrees, and is pointless to use.

It will affect cursor muscle memory if you have image scaling enabled, such as fullscreen, or maintain aspect ratio, as the image is being upscaled. The cursor moves in pixel increments, so scaling the image will also scale your input. It will only affect rotational muscle memory if you: reduced resolution, disabled image scaling (fullscreen, maintain aspect ratio) changed aspect ratio, enabled image scaling (fullscreen) Scenario 1 will change the physical size of the image, changing the focal length. The game will be more zoomed out. The fov is the same, but only because there are black borders instead of rendering more fov. So the sensitivity will need to be changed to account for what the fov should be, then muscle memory would be preserved. Scenario 2 will stretch the image on one axis, skewing the feedback for your input. Horizontal or vertical axis will feel different.

Set y to the same value as x. ...or if you wanted vertical camera movement to be slower/faster than horizontal, multiply x by your arbitrary multiplier that gives you your preferred x:y ratio. e.g. you want vertical to be 70% of horizontal like the old version of Fortnite, giving you a 1:0.7 ratio. x * 0.7 = y

How does the fov formula work? Does it look intentional? Just wondering how they screw it up so badly and haven't attempted to fix it.