View Issue Details

IDProjectCategoryView StatusLast Update
0000447Gameplay + OpenGL[All Projects] Bugpublic2017-03-18 16:14
Assigned To 
Status closedResolutionno change required 
PlatformDesktop ComputerOSWindows 10OS Version64-bit
Summary0000447: Inconsistent mouse-movement with m_noprescale
DescriptionPlaying with m_noprescale set to 'true' along with RawInput being enabled results in odd behavior that does not produce 1:1 mouse ratio as expected.

With mouselook and yaw being set to 1, it seems as if GZDoom distorts the mouse ratio to be 1:2, meaning that looking up and down seems to be twice as fast.
Steps To ReproduceForce RawInput with in_mouse "3" if haven't already.

Set m_noprescale "true"

With pitch, yaw and everything set to 1-- move the mouse around and notice how inconsistent turning around is comparing looking up/down.
Additional InformationCan be remedied with m_pitch "0.5", but I'd rather have a surefire consistent fix for DM.
TagsNo tags attached.



Graf Zahl

Graf Zahl

2017-03-18 07:41

administrator   ~0001040

The whole point of this CVAR is to NOT prescale the mouse movement and get the raw movement values from the system, inconsistent as they are.

What you are asking for is to change the CVAR to do something it is not supposed to do.


2017-03-18 12:43

reporter   ~0001042

Last edited: 2017-03-18 12:47

View 2 revisions

Thanks for looking into this, but it's odd how this is one of the only RawInputs that seems to have the strange mouse movement while other games with RawInput don't have that.

There are only a select few games that have the same behavior as this source-port, but most of the community (especially Elder Scrolls: Skyrim) report it as an annoying bug.

Are you sure this is intended behavior? Rachael definitely thinks this is odd behavior as well, so I think it should be investigated.



2017-03-18 14:04

administrator   ~0001043

Yeah, I did - my gaming mouse I have to set m_yaw to 2.8 to have it consistent with the up/down of the mouse.

I didn't think m_pitch is getting the same m_noprescale treatment as m_yaw is.
Graf Zahl

Graf Zahl

2017-03-18 16:11

administrator   ~0001047

Last edited: 2017-03-18 16:13

View 2 revisions

m_noprescale means that the mouse input gets NO treatment whatsoever, and that the raw values get passed through. The scaling is indeed different for x and y, but this is by design!

In fact, the scaling is different for different platforms. RawInput and DirectInput scale x by 4 and y not at all, and on Posix x by 2 and y by 3.

The prescaling is present to even out these oddities, but since this CVAR says "NO"(!!!) prescale, they will reach the game.

Disabling Prescaling is not designed to appply a cheap fixed scaling factor. For that use the intended mouse scale CVARs.

Issue History

Date Modified Username Field Change
2017-03-17 18:18 unRyker New Issue
2017-03-18 07:41 Graf Zahl Status new => closed
2017-03-18 07:41 Graf Zahl Resolution open => won't fix
2017-03-18 07:41 Graf Zahl Note Added: 0001040
2017-03-18 12:43 unRyker Note Added: 0001042
2017-03-18 12:47 unRyker Note Edited: 0001042 View Revisions
2017-03-18 12:47 unRyker Status closed => feedback
2017-03-18 12:47 unRyker Resolution won't fix => reopened
2017-03-18 14:04 Rachael Note Added: 0001043
2017-03-18 16:11 Graf Zahl Note Added: 0001047
2017-03-18 16:13 Graf Zahl Note Edited: 0001047 View Revisions
2017-03-18 16:14 Graf Zahl Status feedback => closed
2017-03-18 16:14 Graf Zahl Resolution reopened => no change required