How sensitivity works or calculates when zoom?

[*Arxeal]

I did some test with default setting.
cl_mouseAccel=0, m_cpi=0, m_pitch=0.022, m_yaw=0.022
Screen 16:9, full screen mode

When not zoom
Sensitivity 16363.5(Close to 2^14), one dot mouse move = 360 degrees.
With different fov, result are same.

When zoom (zoomsensitivity=1)
Fov=100 zoomfov=22.5 ; Sensitivity 65254.5, one dot mouse move = 360 degrees.
Fov=50 zoomfov=22.5 ; Sensitivity 28344.5, one dot mouse move = 360 degrees.
Fov=100 zoomfov=45 ; Sensitivity 32038, one dot mouse move = 360 degrees.
Fov=100 zoomfov=50 ; Sensitivity 28723.5, one dot mouse move = 360 degrees.

I suspected many algorithm, like:
A. fov/zoomfov
B. tan(fov/2)/tan(zoomfov/2)
C. WS-fov/WS-zoomfov (WS means Widescreen, e.g.:100->115.63)
D. tan(WS-fov/2)/tan(WS-zoomfov/2)
The closest one is "0.9*[cg_fov]/[cg_zoomfov]*[sensitivity]", but still not perfect correct.

Can someone tell me how sensitivity works or calculates when zoom?

[Lorfa]

The sensitivity is multiplied by k where

k = arctan[ 0.75 * tan[cg_zoomfov/2] ] / arctan[ 0.75 * tan[cg_fov/2] ]

zoomfov and fov are in degrees so make sure to specify that when inputting into any kind of calculator as it often assumes radians.

The result is multiplied by cg_zoomSensitivity which defaults to 1.

When cg_zoomSensitivity is 0 it uses a different algorithm, that algorithm is:

k = arctan(tan(zoomfov° * (pi/360)) * height/width ) * (360/pi) / 75

This one cannot be manipulated with cg_ZoomSensitivity as it must be set to 0 to invoke it (it is the old, inferior q3 zoom algorithm).

I'm not sure what you mean by one dot, even on a 400 cpi mouse one "count" occurs every 63.5 micrometers which I cannot imagine you are performing on the pad with any certainty unless you have quite a fancy setup.

With in_mouse 2 and assuming no other driver influences which in_mouse 2 is supposed to bypass but in some cases does not:

Sensitivity 1, m_yaw 0.022 means a 0.022 degree turn per mouse count. There are a maximum of 65536 iterations in a 360, so some counts will be ignored under sens 1 m_yaw 0.00549316406 (360/65536). Similarly, mouse movement will be rendered meaningless with sensitivity 1, and m_yaw 360 or multiples of 360, as all turns will end up in exactly the same spot.

[*Arxeal]

If with sensitivity x, one dot mouse move = 360 degrees.
It means with sensitivity 1, I need x count to turn 360 degrees.
e.g. 360/0.022=16363.6 close to my testing 16363.5.
I use this method to calculate the k by comparing x.

And thanks for the algorithm.
k = arctan[ 0.75 * tan[cg_zoomfov/2] ] / arctan[ 0.75 * tan[cg_fov/2] ]
It still not fit testing result, If this algorithm need some fix when widescreen mode?
If multiplied k by "0.80966", then can fit (Fov=100 zoomfov=22.5)(Fov=100 zoomfov=45)(Fov=100 zoomfov=50) but still can't fit the (fov50 zoomfov22.5) result.

Edit:
I did some new test.
When I set fov=100 and zoomfov=100, then the k should be "1".
It's correct when 4:3 window, but after full screen with 16:9, the sensitivity without zoom doesn't change, but the zoom sensitivity does. K is not "1" when widescreen mode even fov=zoomfov.
k = "0.80966", it's the same as the value above.
when fov=50, zoomfov=50, then the k ="0.762465" in widescreen mode.

I call it "widescreen multiplier", "k" form the algorithm need multiplied by it in widescreen, and it only change by "fov" not "zoomfov".
But, where the value from? "0.80966" with fov 100 and "0.762465" with fov 50.

[Lorfa]

I tested it in a similar way and got the same results.

I used fov 100, and zoomfov 100 at 16:9. I noticed that when I set zoomfov to 99, if I moved the mouse right it would turn left and vice versa. This is not because the game was turning me left, it's because it was making only part of a 360, so it would make an entire rotation but stop short of the previous position.

I used this to gain information about whether the result of the algorithm * sens was making a sensitivity lower than 360, or higher than 360. At 16:9 fov 100, the value I got for zoomfov when everything stopped was 89.605. That makes absolutely no sense. However, since my display is 4:3, and 16:9 shows up very strangely using less than half the screen, it's possible that it is auto-correcting for whatever abomination was actually displayed. However, it was still shorter vertically than horizontally, so my fov should have increased from 100, and as a result the algorithm should not have reported 1 (or close to 1) from zoomfov 89.605.

When you change from 4:3 fov 90 to 16:9 your fov is actually 106.x despite that it says 90. However when I increased cg_zoomfov to compensate in a way I thought was correct, I didn't manage to get the same sens when zooming (yaw 360).

I hope this 360 method is flawed somehow, or it would mean that the algo is incorrect for 16:10 and 16:9, and is not corrected by any correction factor in the game.

I can't seem to find the equation used to calculate fov for different aspect ratios at the moment, but when I find it it might help shed some light on the problem.

[*Arxeal]

I know the fov fix for widescreen, fovB=arctan[tan(fovA/2)*(ratioB/ratioA)]*2.
If use fov=115.6335562(100),zoomfov=29.70763296(22.5) to calculate the k, The result is still not fit the test.
And because the "widescreen multiplier" is only effected by "screen ratio" and "fov", not "zoomfov", It must be something outside the "K's algorithm".
The "K's algorithm" means it need the same mouse count to move 75%/2 screenwide, with zoom or without zoom.
So, why there is a "widescreen multiplier" only relate fov not zoomfov?
Anyway, sorry for my bad English...

[Lorfa]

Not sure I understand what you mean in that last post, but I think you have discovered an important bug!

When fov = zoomfov k should be 1 at _any_ aspect ratio. What we find is that this appears to be true at 4:3, but not at 16:10 or 16:9, and perhaps not at 5:4 either, which is sufficient to say that there appears to be a bug.

What's even stranger is that I ran the test again, this time windowed at 16:9. At cg_fov 100, zoomfov behaved like k was = 1 at 83.5825, of course with m_yaw 360 sens 1 we don't know if k = -1 or any integer. I also got a 1 behavior around fov 117, higher than the 115.6335562269 reported by http://www.emsai.net/projects/widescreen/fovcalc/

I thought I read somewhere that the calculation that site uses is for q3 and doesn't apply to QL. So perhaps the way that QL calculates the horizontal fov is different (better?) somehow. Still we have a problem because it appears that QL isn't taking this different fov into account.

[*Arxeal]

"What's even stranger is that I ran the test again, this time windowed at 16:9. At cg_fov 100, zoomfov behaved like k was = 1 at 83.5825"
This value is interesting, 83.5825(4:3) can transfer to 100(16:9) with fov fix. Actually it's "83.58165703", not same but close enough.
You found the key to explain this problem!

Edit:
I know how it calculate now, and it must be a bug.
WS-k = arctan[ 0.75 * tan[cg_zoomfov/2] ] / arctan[ 0.75 * tan[Bug-fov/2] ]
Bug-fov=arctan[tan(cg_fov/2)*(4/3/WS-ratio)]*2
e.g. If 16:9 the WS-ratio=16/9
Bug-fov is smaller than normal fov, unless your ratio is 5:4.

The correct situation is:
Before zoom, to aim a target at 0.75*half-screenwide pixel far from screen center, we need X count mouse move.
After zoom, to aim a target at 0.75*half-screenwide pixel far from screen center, we still need the same X count mouse move, because of the correct algorithm.
In wide screen mode, the "k" is not correct, and we can change zoomsensitivity to fix it.
Calculate WS_k and k, change zoomsensitivity = (k/WS-k)

[Lorfa]

Ahh ok, I wasn't quite able to calculate that equation as is, so I used this:

bug_fov = [2 * atan(((ratio_OLD) / (ratio_NEW)) * tan((zoomfov°) / 2))] * 180/pi

For example:

bug_fov = [2 * atan(((4/3) / (16/9)) * tan((zoomfov°) / 2))] * 180/pi

bug_fov = [2 * atan((1.33333333333 / 1.77777777778) * tan((zoomfov°) / 2))] * 180/pi

bug_fov = [2 * atan((1.33333333333 / 1.77777777778) * tan((100°) / 2))] * 180/pi

bug_fov = 83.58165703

I already made a bug report about it. Will add this info.

[Lorfa]

Ok.. some more thoughts (was also in bug report):

WS-k = arctan[ 0.75 * tan[cg_zoomfov/2] ] / arctan[ 0.75 * tan[bug-fov/2] ]

bug_fov = [2 * atan(((ratio_OLD) / (ratio_NEW)) * tan((fov°) / 2))] * 180/pi

So at say 16:9 for example, cg_fov says 100, you set zoomfov to 100, the sens is not the same. If you set cg_zoomfov to bug-fov, it will be the same.

Looks like the value of cg_fov is:

A. Calculated correctly for the view at the new aspect ratio, so like 90 probably becomes ~106 when going from 4:3 to 16:9

B. cg_fov is multiplied by some factor internally and this result is made available to the zoomsens calculation. However, zoomfov is missing this internal correction, and so k = 1 only when zoomfov is manually run through the bug_fov formula above.

C. The formula used may be incorrect, as the division may be accidentally reversed. Watch the case of fov 90; here new_fov will be the corrected fov when going from a 4:3 screen to a 16:9.

New fov = [2 * atan(((ratio_OLD) / (ratio_NEW)) * tan((fov°) / 2))] * 180/pi
New fov = [2 * atan(((4/3) / (16/9)) * tan((90°) / 2))] * 180/pi
New fov = [2 * atan(((1.33333333333) / (1.77777777778)) * tan((90°) / 2))] * 180/pi
New fov = 73.739795291

We know this isn't right because we were at fov 90 before and it should be getting higher going to wide screen.

Now watch the same with ratio_old and ratio_new reversed:

New fov = [2 * atan(((ratio_NEW) / (ratio_OLD)) * tan((fov°) / 2))] * 180/pi
New fov = [2 * atan(((16/9) / (4/3)) * tan((90°) / 2))] * 180/pi
New fov = [2 * atan(((1.77777777778) / (1.33333333333)) * tan((90°) / 2))] * 180/pi
New fov = 106.260204709

This is definitely the expected value. However setting zoomfov to this does not make the sens the same.

As further evidence, when zoomfov = fov, the sensitivity did get slightly higher. This is consistent with k being > 1

It's also consistent with a measurement I did:

I set fov 100 zoomfov 100, and a 16:9 resolution. I then placed the mouse between two barriers and moved between them taking note of the viewpos values at start and finish. When zoomed the sensitivity was ~26% higher based on the average difference of a bunch of tests, rather, it turned ~26% more degrees.

I did some calculations, and for example sens 4 comes out to sens 4.94, and the difference in degrees/cm between those two is close to 26%, within an error margin for the test I was doing.

[*Arxeal]

You have got the equation, because ratio_OLD=4/3.
If degrees "Bug-fov°=arctan[tan(cg_fov°/2)*(ratio_OLD/WS-ratio)]*2"
If radians "Bug-fov°=arctan[tan(cg_fov°*pi/180/2)*(ratio_OLD/WS-ratio)]*2*180/pi"

In the case fov 90 zoomfov 22.5 with 16:9 screen.
Change 90 to 73.739795291 isn't right obviously.
If change it to 106.26, both fov and zoomfov should change, or neither. Or the algorithm would be meaningless.
If neither changed, the algorithm will make sure 0.28125%(equal to 50% height) screen-width-move need same mouse count, with or without zoom.
If both changed, the algorithm will make sure 37.5% screen-width-move need same mouse count, with or without zoom.

My English is not good, your bug report would be helpful, Maybe you can add this thread's Url.