Need slightly more clarification on monitor distance matching

[Bernd Matthys]

Little problem with the WPS multiplier in view speed modus.

 

When converting from desktop to a WPS independent game using view speed modus the calculator doesn't take the "real movement speed" into account.
It just copies the DPI value from the desktop to the game. Instead the calculator should recalculate the real desktop movement speed

 

 

This is wrong because the "real movement" speed should be calculated on 540DPI instead of 2160DPI since WPS 3 = 2160dpi * 0.4 = 540 DPI

 

like i changed here.

 

 

 

Like this.

So when a game is WPS independent the calculator should first recalculate the real desktop movement speed so in this case 540 DPI and use that instead. (while it can still show 2160DPI @ WPS:3)

For me this isn't a problem but for other less experienced users this can be confusing.

Edited March 13, 2017 by Bernd Matthys

[DPI Wizard]

Correct, the WPS was applied twice. Check it now

[DPI Wizard]

Chord distance could also be an input value, in addition to 360 distance and sensitivity.

Technically you do this with Windows / Desktop as input. HRES/DPI = Chord Length, as with 2560/400 = 6.4 inches. You can use what ever DPI you want for the output game. Do say you want chord length 10 inches, that would be 256 DPI for Windows. Then enter 400 DPI or whatever for the game you are converting to. 

 

fyi you cant convert using viewspeed from windows, it defaults to only allowing you to use monitor distance

This and a few other bugs need to be sorted out, so I'm removing the viewspeed for a little while to work on them.

[Skwuruhl]

When to the point of:

360°/103FOV (10.16cm - 14.85244011%) = 30.236477 cm

Which can be rewritten as

360°/103FOV * 10.16cm * (1 - 14.85244011%) = 30.236477 cm

Are you sure that you shouldn't instead do

360°/103FOV * 10.16cm / (1 + 14.85244011%) = 30.9185 cm

It's a small difference at this FOV but at higher FOVs it could make a significant difference.

 

Note that using "1 + 14.85244011%" is the same as doing

360°/103FOV * 10.16cm / (2940.2224/2560) = 30.9185 cm

Or

360°/103FOV * 10.16cm * (2560/2940.2224) = 30.9185 cm

At a theoretical 179 FOV this is the difference between 13.08cm/360° and 8.94cm/360°

 

That's up to a 46% difference. Realistically you'd be nowhere near 179 FOV but still.

 

*numbers taken from http://www.mouse-sensitivity.com/forum/topic/582-need-slightly-more-clarification-on-monitor-distance-matching/?p=5985

Edited March 15, 2017 by Skwuruhl

[Drimzi]

Edited January 28, 2018 by Drimzi

[DNAMTE]

When to the point of:

360°/103FOV (10.16cm - 14.85244011%) = 30.236477 cm

Which can be rewritten as

360°/103FOV * 10.16cm * (1 - 14.85244011%) = 30.236477 cm

Are you sure that you shouldn't instead do

360°/103FOV * 10.16cm / (1 + 14.85244011%) = 30.9185 cm

It's a small difference at this FOV but at higher FOVs it could make a significant difference.

 

Note that using "1 + 14.85244011%" is the same as doing

360°/103FOV * 10.16cm / (2940.2224/2560) = 30.9185 cm

Or

360°/103FOV * 10.16cm * (2560/2940.2224) = 30.9185 cm

At a theoretical 179 FOV this is the difference between 13.08cm/360° and 8.94cm/360°

 

That's up to a 46% difference. Realistically you'd be nowhere near 179 FOV but still.

 

*numbers taken from http://www.mouse-sensitivity.com/forum/topic/582-need-slightly-more-clarification-on-monitor-distance-matching/?p=5985

 

Simply because the percentage to be used is 14.85244011%.

 

You can Re write it as:

 

360°/103FOV * 10.16cm * (1 - 14.85244011%) = 30.236477 cm

 

Or more simply:

 

360/103FOV * 10.16cm * (0.851475599) = 30.236477cm

 

 

If you decide to now use:

 

360°/103FOV * 10.16cm / (1 + 14.85244011%) = 30.9185 cm

 

Or more simply:

 

360°/103FOV * 10.16cm / (1.1485244011) = 30.9185cm

 

 

Your dividing and multiplying using two different base values. I'm not exactly understanding where your going with this one.\

 

 

For example if I take 10 and multiply it by 0.5 (50% of itself) = 5.   

 

I Cannot then decide to get the same answer by calculating 10 divided by 1.5 = 6.666

When in fact the correct value is 2. 10 / 2 = 5

 

Correlating to

 

360/103FOV * 10.16cm / (30.236477cm) = 1.17443178

 

360/103FOV * 10.16cm / (1.17443178) = 30.236477cm

 

Edited March 16, 2017 by DNAMTE

[DPI Wizard]

Viewspeed calculations are back.

[Skwuruhl]

Simply because the percentage to be used is 14.85244011%.

 

You can Re write it as:

 

360°/103FOV * 10.16cm * (1 - 14.85244011%) = 30.236477 cm

 

Or more simply:

 

360/103FOV * 10.16cm * (0.851475599) = 30.236477cm

 

 

If you decide to now use:

 

360°/103FOV * 10.16cm / (1 + 14.85244011%) = 30.9185 cm

 

Or more simply:

 

360°/103FOV * 10.16cm / (1.1485244011) = 30.9185cm

 

 

Your dividing and multiplying using two different base values. I'm not exactly understanding where your going with this one.\

 

 

For example if I take 10 and multiply it by 0.5 (50% of itself) = 5.   

 

I Cannot then decide to get the same answer by calculating 10 divided by 1.5 = 6.666

When in fact the correct value is 2. 10 / 2 = 5

 

Correlating to

 

360/103FOV * 10.16cm / (30.236477cm) = 1.17443178

 

360/103FOV * 10.16cm / (1.17443178) = 30.236477cm

 

The 14% is equal to (2940.2224/2560-1)

You're then subtracting this from one making your multiplier (1-(2940.2224/2560-1)) simplified (2-2940.2224/2560)

 

It seems that it would make a lot more sense for the multiplier to be simply (2560/2940.2224)=87.07%

[DNAMTE]

The 14% is equal to (2940.2224/2560-1)

You're then subtracting this from one making your multiplier (1-(2940.2224/2560-1)) simplified (2-2940.2224/2560)

 

It seems that it would make a lot more sense for the multiplier to be simply (2560/2940.2224)=87.07%

 

Now I understand where your coming from. I think you've highlighted an Error.

 

 

Although we need to 'reduce' Arc length/speed by the increase from Chord to Arc, we are negating the percentage from an ARC measurement therefore we must use it in this manner; 'Percent Decrease from ARC to Chord'

 

 

Resulting in:

 

12.931758446299706% is the percent Decrease from Arc to Chord.

14.852440126890471% is the percent Increase from Chord to Arc.

 

 

(360 / 103) * (10.16 - (10.16 * (12.931758446299706%))) = 30.9185243

 

 

We can check this by comparing this from the original 100% Monitor Match sum of:

 

10.16  (360 / 103) = 35.5106796

 

30.9185243 + 14.852440126890471% = 35.5106796 - Thus showing that we have reduced the arc length/speed by exactly 14.852440126890471% (Percent Increase from Chord to Arc).

 

 

 

Thanks for highlighting this, I'm not sure if the Wiz has pasted the same error in to the calc, will have to check!

 

 

 

[Drimzi]

Edited January 28, 2018 by Drimzi

[Skwuruhl]

Here is a more simplified version done by Wolfram Alpha:

 

http://www.wolframalpha.com/input/?i=(4+%CF%80+z+sin(x%2F2))%2Fx%5E2+where+x+%3D+103*pi%2F180+and+z+%3D+2.54*2560%2F640

(4 π z sin(x/2))/x^2

'z' is the distance to go across the screen at desktop. (resolution/DPI (optional: *2.54 for cm instead of in))

 

'x' is the fov in radians

[Drimzi]

Edited January 28, 2018 by Drimzi

[DPI Wizard]

You are a math wizard.

Absolutely 

 

Fixing the calculations now, viewspeed offline while I work on it.

[DPI Wizard]

Check it now

[DNAMTE]

Great stuff. Nice to see everyone chipping in to get this perfect! Will be worth the effort.

[Skwuruhl]

According to this the "optimal" sensitivity for Overwatch would have a 69.5% screen distance match from hipfire to Widow/Ana.

 

For CS:GO hipfire to zoom 1 it'd be 69.3%

 

In fact, all zoom combos I've tried are around 69%. Even with something like 149/150 (zoomed/hipfire) you only get 61% screen distance. Or the other extreme with 5/150 you get 67%. Going another extreme of 5/20 you get 70.7%. The only time you really start to get away from this range is when you use something like 179 degrees as your hipfire and 178 as your zoom where you get 50%. This increases again towards ~70% as you increase the zoom amount from 179. As a final example 102/103 is 68%.

 

As wolfram is unable to solve the relation due to it's complexity I'm not sure what to make of this. Either there's something special about screen distance matching in this range or the error from arc to chord is being applied incorrectly still.

 

Two equations I've been using:

http://www.wolframalpha.com/input/?i=(a%5E2+sin(b%2F2)+csc(a%2F2))%2Fb%5E2+where+a%3D51*pi%2F180+and+b%3D103*pi%2F180 to find (hipfire cm/360)/(zoom cm/360)

 

http://www.wolframalpha.com/input/?i=arctan(xtan(51%C2%B0%2F2))%2Farctan(xtan(103%C2%B0%2F2))%3D0.445683+solve+for+x X is the screen distance match and arctan(x...)/arctan(x...) is basically the former but for screen distance match. That is: (hipfire cm/360)/(zoom cm/360)

 

Note: setting these equal to eachother and asking to solve for X would give you the relation as a graph, however wolfram is unable to do this. Likely due to the arctan(x...)/arctan(x...). I've been doing it manually instead but to construct an actual graph this way would take an unfeasibly long amount of time.

 

It is worth mentioning that 69% is very close to the 75% that CS:GO, BF1, and other companies decided to make their default zoom normalization.

 

Also with all that said: if it spits out sensitivities that feel good then there's not really a "problem" but I'd still like to solve it.

Edited March 17, 2017 by Skwuruhl

[Drimzi]

Edited January 28, 2018 by Drimzi

[DNAMTE]

The problem i have with comparing Monitor Match and Velocity or 'viewspeed' is that they are completely different.

 

With view speed there is only ONE perfect match, with Monitor Matching it's anyone's preference. Somewhere along the 'line' you will match the value of view speed and Monitor Matching, wherever their paths may cross.

Battlefield 1 notes behind their Universal Soldier Aim implementation of Monitor Distance Matching they essentially went by 'feel' and adopted CSGO's core value which is remarkably similar to applied view speed calculations.

 

I see two major problems with this comparison. The first is that any two ARC lengths from our pool of >0 to 180, (most being somewhere in the middle) don't have that much of a discrepancy in length. This alone will make results very tightly bunched when compared to monitor distance % matching.

 

Secondly, the closer we approach 0, the closer we are to FLAT. the less notable difference ANY monitor match percentage will have to differentiate between values as there's such little difference between ANY value. This after all is the major flaw with Monitor Distance Matching, It's perfect at ~0 degrees, from there on the match becomes increasingly less consistent throughout the field of view range. 

 

IMO its a case of apples and oranges, Always look forward to new ideas though!

[Skwuruhl]

I tried your equation but without the variables. I used the equation instead of 0.445683

arctan(xtan(51°/2))/arctan(xtan(103°/2)) = ((51*pi/180)^2 sin((103*pi/180)/2) csc((51*pi/180)/2))/(103*pi/180)^2 solve for x

It comes up with 0.694578 and it plots the graph with -0.69457830 & 0.44568286 and 0.69457824 & 0.44568285.

 

What is the graph suppose to be?

The graph shown is just arctan(xtan(51°/2))/arctan(xtan(103°/2)). You're asking wolfram "for what values of X is arctan(xtan(51°/2))/arctan(xtan(103°/2)) equal to ~0.445683". The value 0.69457824 is the screen distance match for this given ratio of sensitivities. The ratio being 30.9185/69.3734 for 2560p & 640 DPI between hipfire/zoom.

 

My note was if you tried setting them equal with all variables. Like so: http://www.wolframalpha.com/input/?i=arctan(xtan(a%2F2))%2Farctan(xtan(b%2F2))%3D(a%5E2+sin(b%2F2)+csc(a%2F2))%2Fb%5E2+solve+for+x

Edited March 17, 2017 by Skwuruhl

[Skwuruhl]

The problem i have with comparing Monitor Match and Velocity or 'viewspeed' is that they are completely different.

Somewhat fair I suppose. But the whole point of this was that just using one universal screen distance match isn't good enough. I've shown that virtually all usual FOV values are replaceable with 70% and you'd never notice the difference.

For example: CS:GO http://i.imgur.com/1JUzAtR.png & http://i.imgur.com/cBpL7yn.png

The difference is literally 0.25%

Overwatch is pretty much the same thing. Except the difference is 0% because Overwatch doesn't go that accurate.

With view speed there is only ONE perfect match, with Monitor Matching it's anyone's preference. Somewhere along the 'line' you will match the value of view speed and Monitor Matching, wherever their paths may cross.

Yes but it's odd that they're all crossing at pretty much the same point.

I see two major problems with this comparison. The first is that any two ARC lengths from our pool of >0 to 180, (most being somewhere in the middle) don't have that much of a discrepancy in length. This alone will make results very tightly bunched when compared to monitor distance % matching.

I mean they have a linear discrepancy. If you double your FOV you double your arc length.

Secondly, the closer we approach 0, the closer we are to FLAT. the less notable difference ANY monitor match percentage will have to differentiate between values as there's such little difference between ANY value. This after all is the major flaw with Monitor Distance Matching, It's perfect at ~0 degrees, from there on the match becomes increasingly less consistent throughout the field of view range.

Yet it still spits out what's basically 69% for all zoom values that matter.

[Drimzi]

Edited January 28, 2018 by Drimzi

[DNAMTE]

The concept of Monitor Distance matching is flawed. Given that Monitor distance matching covers 100% of your viewspace, obviously somewhere a value will match viewspeed. This does not mean anything relevant.

​If you look at 100FOV. Using Monitor Distance Matching & view speed we have the exact same arc length with either method.

If the value they cross is 70% (I don't know I'm assuming) then this is the range on the arc where the two methods crossover. I would expect this value to drift in correlation to Monitor Distance Matchings expanding inaccuracy with increasing FOV.

 

You are comparing two arcs of EXACT length, the only difference is the increasing misalignment from Monitor Distance Matching as we expand to larger FOV.

 

 

​"With my DPI it only drifted out by 2.3cm at 179 FOV" - Given that A complete 360 takes only 20.8709cm at this FOV, 2.cm is a substantial difference of ~10%. - 400dpi used for comparison.

 

Do not take lightly percent increase/decrease, it's relative to the selected FOV. If We had a match of 70.45673% across ALL FOV then I would know we have an error. We don't, the entire range from >0 - <180 changes accordingly.

Edited March 18, 2017 by DNAMTE

[WhoCares?]

My concern is that a lot of games (not to say most...) dont have adjustable aim down sights sensitivity :/

I mean it's really good when 2D viewspeed and 3D viewspeed are the same,..it feels amazing; but you cant use it in a lot of games.

In the other hand the implementation of a match at 75%screendistance is a solide choise and used in most games.

I am not sure If I am going to stick with 75%, or using viewspeed in all game where it is possible.

For 2D to 3D-hip fire, I will use viewspeed no doubt.

 

Still, viewspeed is definitely the superior method, and I hope more games will support adjustable aim down sights sensitivity in the future! (I know a lot wont, but hope dies at last ^^)

Edited March 20, 2017 by WhoCares?

[Drimzi]

Edited January 28, 2018 by Drimzi

[WhoCares?]

@Drimzi

Just for interest...dont all Cod's have monitor match at 0% ? Do Bo2, Bo3 and IW differs from eachother?