[Closed] Separate X and Y mouse sensitivity

[Marisa Kirisame]

A certain commit has completely thrown me off and everything just feels weird now. Horizontal aim is now too fast and vertical aim is too slow, and there is nothing I can do about it. I'm so used to the old way mouse scaling worked that now it's almost impossible for me to play the damn game.

[Matt]

What was the motivation for this change? Was it causing desyncs in multi?

[Marisa Kirisame]

I doubt it would possibly cause desyncs. I've played with Windows users for a long time and never had any desyncs due to how I moved the mouse.

[phantombeta]

It can't cause desyncs, no. This is all done in the platform-specific input code, and it never reaches the rest of the engine.

What was the motivation for this change?

The motivation appears to have been simply consistency, because it was a strange difference between platforms that didn't seem to make much sense.
Perhaps the original, strange scaling was done to account for some kind of difference between the values that the different platforms return.

[drfrag]

Probably that was the case. @mjr4077au Have you done some testing after your change? I assume you did. _mental did something similar afterwards for Mac so it seems it works well there.

[drfrag]

On windows without prescaling horizontal sensitivity is very low seems that's not the case with SDL. Until this is clarified i've reverted the commit in LZDoom.

[Marisa Kirisame]

Can this be closed? I'm dumb and didn't realize these already exist (turning speed / mouselook speed).

[Graf Zahl]

I reverted that commit. The complaints I got could not be ignored. The different scaling was there for a reason, after all.

[drfrag]

Yeah i reverted it long ago and for Cocoa according to what _mental_ said ("On macOS, horizontal and vertical movements seem to be more or less identical without prescaling") i changed it to:

Code: Select all • Expand view

   if (!m_noprescale)
   {
      x *= 2;
      y *= 2;
   }


[mjr4077au]

Sorry I never saw this bug report and tagging me with an @ doesn't flag anything. Why would we want the port to feel inconstant between operating systems? The first thing I thought when I used GZDoom under Linux was "wow the mouse feels fucked" and I had to fix the axis scaling locally to try and get it right.

Regarding whether I tested it, of course I did and my comments on where this originated are here: https://github.com/coelckers/Raze/pull/81

[_mental_]

In general, it’s a bad idea to modify something that wasn’t changed for many years. Even if the initial implementation was wrong. It’s especially true when no option is provided to bring it back.

[mjr4077au]

In general, it’s a bad idea to modify something that wasn’t changed for many years. Even if the initial implementation was wrong. It’s especially true when no option is provided to bring it back.

Look that's definitely fair enough. I'm just really big on uniformity and don't think things should feel different between OSs. I don't know about macOS but at least between Windows and Linux, it handles the mouse the same so making the backend identical made the mouse feel identical. Reversion here has also made it reverted in Raze where I've worked very hard on uniformity for the release we've just had.

Linux isn't my primary workhorse, I mostly have it for testing purposes. Just feels like we got one complaint by a user who unfortunately didn't know about the axis options and we reverted a change, unless there were others beyond this forum post.

[Graf Zahl]

This was not the first complaint for making a "needless change" we received. I understand your problem, but let's not forget that all Linux users have set up their system to the code as it was, even if the difference was due to some ancient bugs in ancient libraries that have long been tossed out.

Right now the only option I see to make handling uniform is to migrate existing configs by changing the scale so that it still feels the same.

[mjr4077au]

This was not the first complaint for making a "needless change" we received. I understand your problem, but let's not forget that all Linux users have set up their system to the code as it was, even if the difference was due to some ancient bugs in ancient libraries that have long been tossed out.

Right now the only option I see to make handling uniform is to migrate existing configs by changing the scale so that it still feels the same.

That sounds nice but it's also extra code complexity that probably isn't really worth it. Ultimately it's a change I put forward because I didn't like it coming from Windows, but arguably macOS/SDL platforms get it right over Windows 2:1 so who's to say that Windows is right in this instance.

I know how to scale the axes how I want since I know what the backend is doing to them so I'll just sort it out locally and go from there. Still would be nice to have it uniform, but I won't push the issue.

[Graf Zahl]

I hear your words, but I also hear the complaints of the users whose carefully crafted setup is no longer working. What am I supposed to do then? Realistically the only chance to satisfy both sides is to make sure that existing configs get transparently converted so that the internal scaling can be unified. As for Macs, don't ever expect that Apple stuff works like the rest of the world. They give a damn about everything not from them, which even goes as far that they stick to their homegrown keyboard layout, totally ignoring national norms they'd normally be required to adhere to.