Separate X and Y mouse sensitivity

[mjr4077au]

It's always going to be such a subjective matter because everyone will have a different opinion but yeah I'd say this all comes from the GDI input where it applies ballistics and its own acceleration.

So on my setup of Arch Linux and SDL 2.0.12, SDL's mouse feels identical to Windows which is why I did the PR to correct what I thought was wrong. After the change I couldn't tell the difference. The problem with Linux is that this is my distribution with its SDL version but what is Fedora or Ubuntu doing?

I don't know what macOS is doing myself. I have a 2013 MacBook Air that may run Raze and I can try, but it wouldn't be until the weekend. I will try to do some research into this tonight and see what I can find.

[Graf Zahl]

Here's where it really gets weird. I just checked a few other ports for how they handle the mouse.

None of them actually does this prescaling but since all of them also use SDL I cannot say much yet. An old comment from Randi says that the prescaling was a ZDoom specific thing, but back in the day it was only the 3/2 prescaling. The 4/1 version for the raw mouse input seems to be a lot more recent but I haven't been able to find out yet when that got added.

Interestingly, the internal mouse factors for the different means of input the mouse controls are mostly the same. I don't get the entire motivation anyway. It seems to me that the 4/1 version was just added to compensate for fudging done to compensate for the uneven GUI sensitivity.
Raze's GetMouseDelta function multiplies x and y movement with different factors, to actually negate the 3/2 prescaling being done in the backend. I'm sorry but I really do not know what this is all supposed to accomplish - but it'll be a good thing to take this out of the backend and put it under the game engine's control where it can be handled independently.

There's so much fudging going on with the mouse values that it has nearly become impossible to see what the intent of all of this is. At least when looking at the other Doom ports, the pattern was recognizable, but no such luck for Build. Each game is different and there's no pattern to detect because the value scale for angular and directional movement are totally different from Doom's.

[mjr4077au]

I'm not on my proper equipment but I'd be very interested in testing a build at home without any of it and just feel what the actual mouse feels like without all the scaling up and down etc.

Regarding Raze's GetMouseDelta, the (16.f / 32.f) and (16.f / 64.f) for x and y respectively are to mirror how the Build games used to divide the x/y input by 32 and 64 respectively in their getinput() function. I moved that into the backend code some time ago so to save repetition of code. The `/ 3.f` on the end of the x axis has been there since inception and is the true countering divisor.

Given this math with an axis input of 1, the x axis comes out at 0.1667 and the y axis comes out at 0.25. For all that scaling, it ends up being the smaller quantity of the two. What must be considered there is Build uses its own angle and horizon etc, there's no true pitch in the engine so its scaling is required specifically for it.

I think the best approach here would be to get it right in GZDoom first and foremost, then make Raze suit the updated backend.

[drfrag]

For me on windows with any value of in_mouse and m_noprescale set to true x movement is 4 times slower than y movement so it's not surprising that you need to multiply x by 4 to get the same speed. And i'm talking about ingame mouselook here.

[mjr4077au]

For me on windows with any value of in_mouse and m_noprescale set to true x movement is 4 times slower than y movement so it's not surprising that you need to multiply x by 4 to get the same speed. And i'm talking about ingame mouselook here.

What about under Linux? What's your main platform? For me with GZDoom and Raze unless the SDL prescaling matched Windows, the mouse x axis was slower and the y axis was twice as fast. What I'm unsure about is whether that's universal for any Linux distro or just the one I use.

[Rachael]

By that reasoning all config-breaking refactoring would be prohibited.

Well I didn't mean quite that extreme. But in any case I guess I was not quite sure what you meant by the config migration - if you have other plans though, I guess the point is moot.

[drfrag]

My linux desktop died some time ago but i have an old laptop and will check later, hope it still boots.

[mjr4077au]

Sounds great, it'd be good to get some cross-port checks done. Hopefully it boots for you

[Graf Zahl]

After some careful testng on the 3 input modes on Windows I had the following results: The scaling factor 2 for the y axis with GUI input is needed. It's noticably less sensitive in GUI mode than in raw mode.

But it's the X-axis where things get interesting: Here, the GUI is only half as sensitive as the raw mode as well, and yet, GUI gets a prescale of 3 and raw gets a prescale of 4! The code responsible for this dates back to 1998 so the reasons for this weird implementation are lost in time. Fact is, it all makes zero sense and looks broken by design.
So my conclusion is that the 4:1 prescale ZDoom did is an artifact of a probably broken mouse that just became the standard because nobody noticed that the default was bad.

Also interesting: In my personal config I have the prescaling switched off and instead set an overall sensitivity of 1.7, identical for both axes. That config is ancient - I have no idea when I set it up but it must have been over 10 years ago, if not 15. I must have totally forgotten that I changed mouse input this drastically from the default. The 4x horizontal movement scaling is way too fast and definitely broken -I consider it totally unusable. I finally understand now why one of the most frequent complaints toward ZDoom has been that 'the mouse movement is off'. Because it is!

So with that information, here's what I'm going to do: I'm going to remove the fixed prescaling factors entirely and instead implement per-axis sensitivity instead of one global slider - I'll only prescale Windows's GUI input by 2 to match it with the others. And then I'm going to add migration code that reads in the old config values and translates them to the proper way of setting this stuff up. Since the new config will use entirely new CVARs, Rachael's concerns are also addressed when bisecting and going back and forth.

[drfrag]

Those are not my findings with my cheap genius mouse, for me it's the opposite. I've found that 4/2 works better than 3/2 for both GUI? and Linux as the x speed is lower than the y speed but there's not that much of a difference like on the other win32 methods (DInput and raw). The 3/2 version is for in_mouse 1.
And about broken mouse now i set the freelook sensitivity to 1.5 as i find the default too low.
My laptop booted but now the left part of the keyboard is dead so it's a pain to use it.
Edit: notice that when you switch mouses the speed changes but both x and y ones are more similar when using 4/2 for in_mouse 1.

[Graf Zahl]

This just shows that every mouse is different and needs careful calibration - but the 4:1 (not 4:2!) prescale is too extreme.
Nevertheless, I think it's better not to apply magic and intransparent factors to the input but expose the sensitivity factors directly to the user. I've been using that 1.7:1.7 scaling basically since I started using ZDoom 15 years ago, and in that time surely went through 10 mice but never felt it necessary to change it. Yes, I found a backup from 2006 where I could check - it used the same values as there are now.

Yes, I know that there's too many option-menu-impaired people out there but considering the major differences in handling here there is no magical setting that's perfect for everyone. All we can do is get this out and collect some info about what factors feel most comfortable and set the average of our findings as the new default. All I can say is that with a fresh config I found the game totally uncontrollable. X was way too fast and Y was way too slow, using in_mouse = 0 (i.e. RawInput)

[drfrag]

For me 4:1 feels good and few people complain but whatever. I've checked and actually what i set to 1.5 is overall sensitivity.

[Graf Zahl]

So you use 4:1 with 1.5 and I use 1:1 with 1.7.
It should be obvious that with such extreme deviations it makes even less sense to have the magic factor in there.
Most people never complain because they either adjust the controls to their liking or just accept what they are given without even thinking about the option to change it.
But you cannot discount that on Doomworld this came up quite frequently because no other port is doing such a thing.

[mjr4077au]

Definitely going to check this out at home tonight but wanted to ask, can we just make x/y in the event_t struct a float? Currently we get the mouse input as an int, convert to float in PostMouseMove, convert it back to int, convert to double in System_DispatchEvent, convert back to int and then hand it to G_AddViewPitch/G_AddViewAngle.

Feels like more precision could be kept it it's a float right until the end.

[Graf Zahl]

You are maybe right there.
I'm currently working on merging this with Raze, where we fortunately are not restricted this much by old users' habits. I'll see that a sensitvity of 2:2 is what was done here with the 4:1 default of the old backend.