[Closed] Separate X and Y mouse sensitivity

Moderator: GZDoom Developers

Re: Separate X and Y mouse sensitivity

Postby mjr4077au » Tue Sep 29, 2020 1:39 am

Ah right yeah no worries. Sorry was just thinking of Raze where it goes straight to inputState 😂😁
User avatar
mjr4077au
 
Joined: 17 Jun 2019
Location: Gosford NSW, Australia
Discord: mjr4077au#1027
Github ID: mjr4077au
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Separate X and Y mouse sensitivity

Postby Graf Zahl » Tue Sep 29, 2020 1:47 am

One thing here puzzles me a bit - what's up with that prescale factor of 4? drfrag says he needs it, I clearly have no use for it as on my systems both axes have roughly the same sensitivity.
Has something changed in Windows or is there possibly some system side setting affecting the mouse this way or is it just a user preference to have such a sensitive X axis for faster turning?

Considering that I have been using my current settings since XP days the former sounds unlikely but what about the latter?
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Separate X and Y mouse sensitivity

Postby mjr4077au » Tue Sep 29, 2020 1:56 am

I'm going to say, I have to agree with him but I need to test what's been done so far. With either my last mouse (Logitech M720) or current one (Razer Basilisk V2 with 2nd or 3rd lowest DPI setting, can't remember), for both Raze and GZDoom I play them with the mouse completely 100% out of the box and have always found it perfect. This is why I found the pre-scaled pitch of 2x on SDL terrible for me whereas Marisa probably finds it quite normal.

I haven't researched this enough to be sure, but because raw input is exactly what the mouse sends through when polled, the scaling it provides is entirely whatever the hardware provides which could lead to a widely different result from mouse to mouse. Indeed for a shitty throw-in Dell mouse I pinched from work, it's slow and terrible and required massive boosting to its sensitivity when I tested.

From what I've read with GDI mouse code, you're returned mouse movement in pixels, of which you're supposed to scale based on the DPI of the running application or operating system. While it'd have ballistics and all the shit that comes with it, the mouse should be much more consistent from mouse to mouse.
User avatar
mjr4077au
 
Joined: 17 Jun 2019
Location: Gosford NSW, Australia
Discord: mjr4077au#1027
Github ID: mjr4077au
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Separate X and Y mouse sensitivity

Postby Graf Zahl » Tue Sep 29, 2020 2:03 am

You should be correct, but I've been using mice from various manufacturers over the years, from Logitech, Hama, Sharkoon and even some cheap-ass Chinese products and all I had to tweak was the overall sensitivity a bit but I never activated the prescale. So I really do not know what's up, this needs some feedback from other users.

Please do not use Raze as your guideline as its input values were tweaked for that 4:1 prescale it got from the backend, so of course a more toned down 3:2 prescale would feel off. Passing raw values to the game now my sensitivity settings only reflect the different factors the code currently applies. When factoring these out, the constant scale to be applied in GetMouseDelta is 0.5 for both axes, and I'd get perfect behavior out of the box.
Last edited by Graf Zahl on Tue Sep 29, 2020 2:10 am, edited 1 time in total.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Separate X and Y mouse sensitivity

Postby mjr4077au » Tue Sep 29, 2020 2:08 am

This is my quick Powershell math of the old code paths with angle, then pitch. Long story short, even with the pre-scale of 4:1, it only ever ended up as 2:1 for Doom and 2.667:1 for Raze in any case:

Code: Select allExpand view
PS C:\Users\mitch.richters> #Raze at 4:1
PS C:\Users\mitch.richters> 4 * (16/32) * 1 * 1 / 3
0.666666666666667
PS C:\Users\mitch.richters> 1 * (16/64) * 1 * 1
0.25

Final ratio: (8/3):1

Code: Select allExpand view
PS C:\Users\mitch.richters> #Doom at 4:1
PS C:\Users\mitch.richters> 4 * 1 * 1 * 8
32
PS C:\Users\mitch.richters> 1 * 1 * 1 * 16
16

Final ratio: 2:1

I'm hoping other users can chime in but I think for both games, a default out of box 2:1 scale for angle:pitch is probably a desirable starting point, then players can further tweak from there.
User avatar
mjr4077au
 
Joined: 17 Jun 2019
Location: Gosford NSW, Australia
Discord: mjr4077au#1027
Github ID: mjr4077au
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Separate X and Y mouse sensitivity

Postby Graf Zahl » Tue Sep 29, 2020 2:18 am

No idea how it all adds up. That 2:1 ratio for pitch control is present in all Doom engine ports I checked, even those using no prescaling. It may just be that to feel natural, these both factors need to be different. But the fact remains that I've been playing with disabled prescale for years and when I re-enabled it yesterday for the first time it felt totally off.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Separate X and Y mouse sensitivity

Postby mjr4077au » Tue Sep 29, 2020 2:26 am

The 2:1 scale makes sense to me because there's 360 degrees of angle and 180 degrees of pitch so to get an even input you'd need that 2:1 scale.

I honestly couldn't imagine playing without prescale and an even 1.7:1.7, that means your pitch speed was/is twice as fast as your angle given what happens in System_DispatchEvent().
User avatar
mjr4077au
 
Joined: 17 Jun 2019
Location: Gosford NSW, Australia
Discord: mjr4077au#1027
Github ID: mjr4077au
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Separate X and Y mouse sensitivity

Postby mjr4077au » Tue Sep 29, 2020 2:48 am

Yeah, for Raze the y axis is far too fast now. I can go from fully looking down to fully looking up in about 10mm of movement. Currently building GZDoom now to see how it feels.

For Raze, in GetMouseDelta(), I'd change:
Code: Select allExpand view
   hidInput->mouseturnx = finput.x * m_yaw * (1.f / 3.f);
   hidInput->mouseturny = finput.y * m_pitch * 0.5f;


to:
Code: Select allExpand view
   hidInput->mouseturnx = finput.x * m_yaw * (1.f / 4.f);
   hidInput->mouseturny = finput.y * m_pitch * (1.f / 8.f);


Alternatively, keep the scaling here identical and make m_sensitivity_y 1 instead of 2 to transparently show that out of the box there's a 2:1 scale.

To clarify also, my playing style is basically zero movement of my arm. I move the mouse as far up/down/left/right as my wrist permits me to do so. With that in mind, I expect to get a reasonable amount of pitch to look up and down as far as typically needed and expect a quick wrist flick to net me a 90 degree turn.

EDIT: Got my code examples wrong.
Last edited by mjr4077au on Tue Sep 29, 2020 2:57 am, edited 1 time in total.
User avatar
mjr4077au
 
Joined: 17 Jun 2019
Location: Gosford NSW, Australia
Discord: mjr4077au#1027
Github ID: mjr4077au
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Separate X and Y mouse sensitivity

Postby Graf Zahl » Tue Sep 29, 2020 2:54 am

So why do the other input methods not apply that prescale then? It never was in Windows GUI and none of the other OSs. I may sound like a broken record but I have no use for it, when I enable prescale with a uniform sensitivity I either get too fast rotation or too slow pitching, it only feels good to me if both are scaled roughly the same with maybe giving the pitch a little less.

I also find it weird that we still got some magic factor in there whose purpose seems to have gotten lost in time. But again, I checked Eternity which has no prescale (it uses SDL for all platforms, though) and uses the same factors as ZDoom for the axes.


mjr4077au wrote:Yeah, for Raze the y axis is far too fast now. I can go from fully looking down to fully looking up in about 10mm of movement. Currently building GZDoom now to see how it feels.

For Raze, in GetMouseDelta(), I'd change:
Code: Select allExpand view
   hidInput->mouseturnx = finput.x * m_yaw * (1.f / 3.f);

   hidInput->mousemovex = finput.x * m_side* (1.f / 3.f);


to:
Code: Select allExpand view
   hidInput->mouseturnx = finput.x * m_yaw * (1.f / 4.f);

   hidInput->mousemovex = finput.x * m_side* (1.f / 8.f);


Alternatively, keep the scaling here identical and make m_sensitivityy 1 instead of 2 to transparently show that out of the box there's a 2:1 scale.

To clarify also, my playing style is basically zero movement of my arm. I move the mouse as far up/down/left/right as my wrist permits me to do so. With that in mind, I expect to get a reasonable amount of pitch to look up and down as far as typically needed and expect a quick wrist flick to net me a 90 degree turn.


I think we should keep magic factors to a minimum, but the default sensitivity scale should be 2:2 so that we got enough maneuvering space in the values.
What's odd here is that you need to half the value for applying movement with the mouse, that's the opposite of what GZDoom does, but I guess it's owed to very different input logic between the games.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Separate X and Y mouse sensitivity

Postby mjr4077au » Tue Sep 29, 2020 3:03 am

I edited my code example to show what I meant, but yes I think horizon/pitch should be half, but GZDoom is effectively doing the same.

This is from System_DispatchEvent(). Assume m_yaw/m_pitch are 1 and we have an x/y input in the event prescaled 4:1.

Code: Select allExpand view
      if (buttonMap.ButtonDown(Button_Mlook) || freelook)
      {
         int look = int(ev->y * m_pitch * 16.0);
         if (invertmouse) look = -look;
         G_AddViewPitch(look, true);
         ev->y = 0;
      }
      if (!buttonMap.ButtonDown(Button_Strafe) && !lookstrafe)
      {
         int turn = int(ev->x * m_yaw * 8.0);
         if (invertmousex)
            turn = -turn;
         G_AddViewAngle(turn, true);
         ev->x = 0;
      }


This is where I got the example pseudo code for Doom that I sent earlier:

Code: Select allExpand view
PS C:\Users\mitch.richters> #Doom at 4:1
PS C:\Users\mitch.richters> 1 * 1 * 16 (Pitch)
16
PS C:\Users\mitch.richters> 4 * 1 * 8 (Angle)
32


With the default prescaling, you'd end up at a 2:1 ratio in any case. This makes perfect sense to me. Without prescaling, you're basically playing like:

Code: Select allExpand view
PS C:\Users\mitch.richters> #Doom at 1:1
PS C:\Users\mitch.richters> 1 * 1 * 16 (Pitch)
16
PS C:\Users\mitch.richters> 1 * 1 * 8 (Angle)
8


Surely you can't play with the angle that's got twice the degrees of pitch at half the amount of pitch itself? Your pitch must be phenomonally fast and your angle must be overwhelmingly slow surely?
User avatar
mjr4077au
 
Joined: 17 Jun 2019
Location: Gosford NSW, Australia
Discord: mjr4077au#1027
Github ID: mjr4077au
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Separate X and Y mouse sensitivity

Postby Graf Zahl » Tue Sep 29, 2020 3:20 am

That setting feels perfectly fine to me. With prescaling on it does not. I also never noticed anything wrong on my work Mac which has 3:2 prescaling. It max be somewhat faster for turning but the factors are close enough. On the other hand I immediately noticed something was wrong when I enabled prescaling. The axis movement ratio just felt totally wrong.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Separate X and Y mouse sensitivity

Postby mjr4077au » Tue Sep 29, 2020 3:59 am

Alright, so GZDoom is very different to Raze... Jumping into GZDoom (I went to 4.4.2 with defaults and admittedly, it's been a little while due to all the effort on Raze) and yes, the angle felt too fast for me with pre-scaling which was unexpected. Horizon out of the box is pretty much on point.

With the current master, and by really fiddling around with the settings to get them pretty much what felt perfect, I ended up with m_sensitivity_x of 2.375 and m_sensitivity_y of 0.875 (both set from the console). Given what we know is in System_DispatchEvent(), we get the following:

Code: Select allExpand view
PS C:\Users\mjr40> 0.875 * 1 * 16
14
PS C:\Users\mjr40> 2.375 * 1 * 8
19

Final ratio is ~ 1.35:1, which I personally found surprising after all the hypothesising before I could test things out.

Pre-scaling under macOS (same pre-scaling as SDL) was no good, but it sounds like it was no good to you because of the pre-scaled x axis whereas it was never good for me due to the pre-scaled y axis that Windows never did.

For Raze though, I still stand by changing these lines to:

Code: Select allExpand view
   hidInput->mouseturnx = finput.x * m_yaw * (1.f / 4.f);
   hidInput->mouseturny = finput.y * m_pitch * (1.f / 8.f);

This restores the horizon to what it was (half of what it is now) and reduces the angle by 33% for a 2:1 scale which I think is appropriate given the games used to divide x input by 32 and y input by 64 using the input code from EDuke32.

Leaving the 1/3 divisor on x which basically mimmicks the / 3 divisor x used to have to compensate for prescaling is probably just a touch too quick. Was the /3 divisor ever based on anything or was it more just a "this feels right" thing during the initial mobilisation and never revisited?
User avatar
mjr4077au
 
Joined: 17 Jun 2019
Location: Gosford NSW, Australia
Discord: mjr4077au#1027
Github ID: mjr4077au
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Separate X and Y mouse sensitivity

Postby drfrag » Tue Sep 29, 2020 4:07 am

But to me that 360º/180º thing doesn't matter, you can move horizontally/vertically only a little or at least less than the full angle/pitch (this is obvious) and in the software renderer looking up/down angles were far more limited than 180º. To me across computers/mouses x movement without prescaling is extremely slow on windows, now i'm testing with a ball logitech mouse and the optical genius mouse. To me 4:1 feels good, and in the pirated ZDoom 2.1.8 build it's the same.
I'm going to merge your changes now and try again.
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: Separate X and Y mouse sensitivity

Postby mjr4077au » Tue Sep 29, 2020 4:10 am

Evidentally from my testing, it's irrelevant because of what I ended up with but from what's been said here you can see why since the pre-scaling of 4:1 ends up being 2:1 by the time System_DispatchEvent() has processed it and multiplied pitch by 16 and angle by 8.

Interested to see what you think after you've merged and had a further play yourself :)
User avatar
mjr4077au
 
Joined: 17 Jun 2019
Location: Gosford NSW, Australia
Discord: mjr4077au#1027
Github ID: mjr4077au
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Separate X and Y mouse sensitivity

Postby Graf Zahl » Tue Sep 29, 2020 4:13 am

viewtopic.php?f=49&t=70027

This needs a bit of public awareness and feedback. Let's hope with more numbers we can make a better decision than with the info from just 4 people (Marisa Kirisame included.)
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

PreviousNext

Return to Closed Feature Suggestions

Who is online

Users browsing this forum: No registered users and 1 guest