Separate X and Y mouse sensitivity

[mjr4077au]

Ah right yeah no worries. Sorry was just thinking of Raze where it goes straight to inputState

[Graf Zahl]

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?

[mjr4077au]

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.

[Graf Zahl]

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.

[mjr4077au]

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 all

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 all

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.

[Graf Zahl]

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.

[mjr4077au]

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().

[mjr4077au]

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 all

	hidInput->mouseturnx = finput.x * m_yaw * (1.f / 3.f);
	hidInput->mouseturny = finput.y * m_pitch * 0.5f;

to:

Code: Select all

	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.

[Graf Zahl]

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.

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 all

	hidInput->mouseturnx = finput.x * m_yaw * (1.f / 3.f);

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

to:

Code: Select all

	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.

[mjr4077au]

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 all

		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 all

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 all

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?

[Graf Zahl]

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.

[mjr4077au]

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 all

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 all

	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?

[drfrag]

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.

[mjr4077au]

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

[Graf Zahl]

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.)