Page 1 of 1
Making Mouse Behaviour Consistent on Windows
Posted: Fri Mar 19, 2010 9:21 pm
by mh
We all know that mouse behaviour in Quake is different depending on whether or not you're using DirectInput. Here's a quick one-liner to make it consistent.
Open in_win.c, find the declaration of newmouseparms. It should look like this:
Code: Select all
static int originalmouseparms[3], newmouseparms[3] = {0, 0, 1};
Change the 1 to a 0, like so:
Code: Select all
static int originalmouseparms[3], newmouseparms[3] = {0, 0, 0};
That's all.
OK, so what's going on here?
Basically these mouse parameters refer to 3 factors that control how the mouse behaves. The first two are acceleration thresholds, and the third is an acceleration level. Setting them all to 0 replicates the behaviour of DirectInput exactly, which is to completely ignore the settings in your mouse control panel and just give flat unaccelerated input.
For bonus points you can cvar-ize them; that's an exercise left to the individual.
Posted: Sat Mar 20, 2010 6:41 am
by r00k
Remember the ol' "I should have had a V8!" slap to the head?
I almost knocked myself outta my chair!
Code: Select all
static int originalmouseparms[3], newmouseparms[3] = {0, 0, 0};//MH: acceleration level set to zero!
Thanks for pointing this out! Legacy anomalies must die!
Posted: Mon Apr 12, 2010 4:14 pm
by mankrip
I'm not sure if this inconsistency was intentional, but it was mentioned in WinQuake's readme:
Code: Select all
----------------------
| Notes on the mouse |
----------------------
If DirectInput is installed and functioning, WinQuake can use it for
mouse input, but does not do so automatically because DirectInput does
not work properly on all systems. DirectInput can be enabled via the
command-line switch -dinput. If DirectInput is not available or is
not enabled, WinQuake uses the normal Windows mouse APIs instead.
DirectInput provides slightly smoother motion; also, it tends to be
more responsive to fast spinning motions, and we recommend that you use
it if it works properly on your system. You can determine if WQ uses
DirectInput on your system when you use -dinput by checking for
"DirectInput initialized" in the startup console text. If not, you
might try installing DirectX 3 (note, though, that as I write this
there is no released DirectInput support for Windows NT, only Win95).
Posted: Mon Apr 12, 2010 5:45 pm
by Sajt
I think DirectInput disables mouse acceleration automatically. When you fix the bug pointed out by mh, DirectInput and non-DirectInput feel identical, although DirectInput is supposedly a couple billionths of a microsecond "more responsive".
Apparently (if I remember what LordHavoc told me) the WinQuake code actually used to work, but there was a Windows API change which changed the meaning of the parameters.
I removed DirectInput entirely from GoldQuake. It's deprecated, and WinQuake uses an old version anyway which only supports 4 mouse buttons among other things.
Posted: Mon Apr 12, 2010 6:30 pm
by mh
Sajt wrote:I think DirectInput disables mouse acceleration automatically. When you fix the bug pointed out by mh, DirectInput and non-DirectInput feel identical, although DirectInput is supposedly a couple billionths of a microsecond "more responsive".
Maybe on the slow CPUs in 1996 it made a difference, but best of luck finding a machine these days where you'd notice.
Sajt wrote:Apparently (if I remember what LordHavoc told me) the WinQuake code actually used to work, but there was a Windows API change which changed the meaning of the parameters.
That would make sense. It always seemed weird to me that there would be such a difference in feeling between the 2 modes. I guess it confirms that moving forward setting the third param to 0 is the way to go, maybe with a OS or DLL version check if we can determine when the change took place.
Sajt wrote:I removed DirectInput entirely from GoldQuake. It's deprecated, and WinQuake uses an old version anyway which only supports 4 mouse buttons among other things.
It's not that difficult to move up to the newer version, but all the same, unless you're committing to Windows-only it does make sense to remove it. The less platform-specific code you need to port, the better.