Separate X and Y mouse sensitivity

[mjr4077au]

I'm basically saying leave it reverted as you have done, the needs of the many outway the singular me . I understand the repercussions of such a change now and it ultimately doesn't matter since it's all adjustable anyway.

[Graf Zahl]

I'd actually have it consistent but let existing configs keep their sensitivity by changing the CVAR, that's less problems in the long run.

[mjr4077au]

So, revert the reversions but keep the old code under "legacy mouse prescaling CVAR"? You'd probably extend the macOS/SQL legacy mode to Windows at that point as well.

[Graf Zahl]

No - out with the cruft, what I'd do is change their scaling CVAR's value in the config migration code.

[mjr4077au]

I didn't know such code existed but that sounds like a great approach if there's migration code for situations like this

[Graf Zahl]

Looking at what the code is doing here - wtf???
It first prescales x by 4, but y not at all, but when the value is applied it again scales x by 8 and y by 16. I am actually very tempted to rip out this bullshit altogether, along with the m_noprescale CVAR, define sensible multipliers and adjust the value range for the sensitivity scalers. There's 3(!) CVARs that affect horzontal mouse movement. Why 3? And why is everything done in totally different places? Why not everything in the one place where it actually gets used?

For the record: We first got the code that receives the mouse movement - depending on m_noprescale it is the first one fudging with the values. It's present 3 times in all backends.
Next we got m_filter. That's in a separate function for Windows and Posix but not for macOS.
And finally we got the sensitivity scalers which are in yet another place but - oh wonder - this one is present only once.

[mjr4077au]

It sounds like everyone has put their two cents in over the course of time... I'm all for getting back to something that's somewhat more pure if it doesn't put users out anymore than I already have .

[Graf Zahl]

Yeah. Interestingly, of the 3 input methods for Windows two used the 4:1 prescale, the other one the 3:2 prescale ratio. Talk about consistency. And now I am quite certain what has happened here and where this inconsistency came from: The original mouse code was Windows GUI events - and these require a different prescale than all other input methods - but as it so happened the Posix backends got the coefficients from the first Windows variant and were never updated afterward.
It really makes no sense how the mouse sensitivity was handled, it looks like several people were messing around with it, each one with their own idea and no common vision to centralize this code.

[drfrag]

Well mouse movement is different across OSes so it can't be consistent. The idea behind mouse prescaling was that x and y speeds were pretty much the same and reasonably fast with the default settings, randi knows for sure. If you disable it on windows x movement is much slower than y movement.

[mjr4077au]

Well mouse movement is different across OSes so it can't be consistent. The idea behind mouse prescaling was that x and y speeds were pretty much the same and reasonably fast with the default settings, randi knows for sure. If you disable it on windows x movement is much slower than y movement.

Raw input between Windows and SDL is identical though, which is why I did the PR in the first place. The mouse under SDL feels very different to Windows due to the 3:2 scaling vs Windows and it's 4:1 scaling. I don't know what macOS does here and whether it's different or not to the other two.

I think centralising this in the event handler once input is received would be the next way, then for the legacy GDI mouse input which I think is still in there, scale it appropriately to match raw input since it's the odd one out.

[Graf Zahl]

Agreed. There was another interesting inconsistency. The Posix backend didn't register any zero mouse movement which pretty much whacked the m_filter setting and rendered it useless - the entire purpose of it is to even out spotty mouse movement, but how can it do that if it doesn't receive these intermediate states?

What I did here was to remove m_noprescale and replace it with m_prescalex and m_prescaley, so that the amount of hackery can be reduced. I expect the GDI backend to require a fudging factor but the rest should be consolidated to do the entire mouse processing in one function, not scattered across the entire code.

[Rachael]

About the config migration, might it be desirable to move the scale CVARs to a new name?

The reason I ask this is because when you go back and forth (which you must do if you are bisecting an issue) and you keep going past the migration point, well, it can cause problems...

i.e. if you have a simple (as an example)

Code: Select all

 if (configver < 221) { m_pitch *= 2; m_yaw *= 2; }

... this balloons into a serious problem very quickly, when bisecting or when switching between release and dev builds.

[Graf Zahl]

By that reasoning all config-breaking refactoring would be prohibited. But no, I do not intend to change these, I intend to change how the prescaling is applied. Instead of a simple yes/no switch, allow specifying actual factors for both axes, i.e. have real axis-dependent sensitivity. Currently we only have one multiplier for both and one for each of the properties the mouse can affect.

[mjr4077au]

Is there any reason to have prescaling at all? No prescaling but a mouse x axis sensitivity of 4 achieves the same thing and is more transparent in my opinion.

[Graf Zahl]

It indeed is. I think the issue comes from a difference in value ranges when using direct mouse input and GUI based input.
That really should have been done better, but so far all I got is complaints but no facts about how the different backends handle mouse input. I can test Windows myself but especially for macOS I need a second opinion from someone who has actually played on both Windows and macOS. Is the 3/2 prescaling needed or just an artifact like on Linux? I don't know. When I last played on a Mac it didn't feel off so my guess is that it's just GUI based input like Windows GDI that needs different factors.