[Closed] Separate X and Y mouse sensitivity

[mjr4077au]

Solid move I feel, it's just too subjective.

Last discussion on Raze here to not clog up the post any further, am I right to commit the changes I've suggested or do you really want to keep the pitch doubled from what it was before? In addition to that, I'll make better use of mousemovex/y that you've added to the ControlInfo struct as well.

[Graf Zahl]

I said that I felt the values needed a bit of tweaking, especially the pitch. I just wanted your opinion first before changing anything.

[mjr4077au]

No worries, just confirming

[mjr4077au]

FWIW, I've been playing a bit with the GDI mouse input codepath and I don't really think it needs any scaling to match raw mouse input. With the scaling, it feels pretty lumpy to me and if I move faster than normal, due to ballistics the generated event is very quick.

Under normal/average movement with the 2x multiplier gone, it feels about the same as raw input to me on my system.

[Graf Zahl]

Ok, I didn't really test out the ballistics, but with the multiplier it felt better on my end. Needs more opinions, but I doubt there's many people using it. Most stick with RawInput, or if that causes problems, switch to DirectInput instead.

[mjr4077au]

I think that one's going to be extremely subjective to the DPI of the mouse that's being used with it. If I lower the DPI on my mouse, it feels OK but felt better at the normal DPI I run at without the multiplier.

Genuinely cannot tell the difference between DirectInput and Raw Input. My understanding was DirectInput (not in our code, but Microsofts) was just a wrapper around Raw Input anyway: https://docs.microsoft.com/en-us/window ... irectinput

"Internally, DirectInput creates a second thread to read WM_INPUT data, and using the DirectInput APIs will add more overhead than simply reading WM_INPUT directly." WM_INPUT is described above and appears to be Raw Input to me.

[Graf Zahl]

DInput has one advantage over RawInput - the handler does not continuously reset the mouse to the center. This can become quite a bit annoying with RawInput.
But good question about the DPI. I'm not sure how this affects different mice. But since the m_input CVAR is hidden in the console it is very doubtful that it sees wide use.

[mjr4077au]

When does resetting the mouse to center become an issue? Probably explains why the cursor is in the center when the game does a GuiCapture .

Me either, but another thing to be mindful with pre-scaling the GDI mouse is that itd be also subjecft to whatever sensitivity that Windows has been set to in the Control Panel so a faster than average desktop cursor when pre-scaled in-game might be rather quick.

Agreed that it's tucked away. I had to comb through the source to even find out how to switch between modes

[drfrag]

the pre-scaling of 4:1 ends up being 2:1 by the time System_DispatchEvent() has processed it

I don't get why you say "ends up", the end result depended on the different initial prescale you put.
I've noticed that actually y speed was slightly slower than x speed with 4:1 and probably it's better that way. With my configs i get 6:1.5 or 4:1 as expected depending of the mouse_sensitivity cvar (1.5 or 1).
With a fresh config and 2:2 the x speed is way too low. Changing 'int turn = int(ev->x * m_yaw * 8.0);' in System_DispatchEvent(event_t* ev) to 'int turn = int(ev->x * m_yaw * 16.0);' you can get the old sensitivity with 2:1 instead which is a more reasonable default. I don't know where the *8 came from but even with *16 x movement is clearly slower.

[mjr4077au]

the pre-scaling of 4:1 ends up being 2:1 by the time System_DispatchEvent() has processed it

I don't get why you say "ends up", the end result depended on the different initial prescale you put.

Using Windows as an example, the initial pre-scale was always x << 2.

Assume all mouse scaling CVARs are 1, an x input of 20 and a y input of 20, and a prescale of x by <<2 (4x):

Code: Select all • Expand 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;
      }

For pitch: 20 * 1 * 16 = 320
For angle: 80 * 1 * 8 = 640

From here, we can clearly see that the final ratio before the input is passed to the game for angle/pitch is 2:1. And that's all I'm saying, that a 4:1 pre-scale ends up being a 2:1 scale before the input is passed to the game.

[drfrag]

I've done some investigation and those mousex * 8 and mousey * 16 were there right from the start in g_game.cpp, actually for mousey was 256 initially and then changed in the C++ conversion (1.18). The *0x8 was even in the original Doom source i believe. The prescale was also there from the beginning (both 4:1 for DInput and 3:2 for GDI, SDL was changed at some point to be "basically identical" to GDI). The m_noprescale cvar was added in 2.0.41 with the following comment:

- Added mouse and joystick option menus. Also added an option not to
prescale the mouse movements. I've done this all along because it
feels like the vertical sensitivity is much higher than the horizontal
sensitivity, so the prescaling compensates for that perceived difference.
But it could be the reason some people gripe that "ZDoom's mouse feels
different from Doom's! It sux0rz delux0rz!" So now they can turn it off
with a single switch instead of messing with the various mouse sensitivities
to decompensate.

It's easy to see that most people use higher values for m_sensitivity_x. And there was a report here (and others in the forum): https://mantis.zdoom.org/view.php?id=447
Now that m_noprescale is gone what about changing that *8 to *16 and adjusting again the defaults for old configs?

[mjr4077au]

I pretty much agree here. Earlier I was commenting on how I thought double the x speed was normal/expected because there's 360 degrees of angle vs 180 degrees of pitch, but I think now if we're going to have m_sensitivity_x and m_sensitivity_y identical out of the box with the expectation they move the same, then both should move the same amount of degrees. Before the angle:pitch was 2:1, now its 1:2 which is drastically different.

As drfrag has pointed out, everyone has their x axis faster than their y axis on our feedback thread (viewtopic.php?f=49&t=70027). The changes he's suggesting will get the x/y ratio closer or (or if not exactly) 1:1.

On the back of this, I'll PM you regarding Raze to keep this topic clean.