Project

General

Profile

Bug #697

Mouse Strafing Extremely Slow

Added by sonicdoommario almost 15 years ago. Updated over 11 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
2009-06-01
% Done:

100%


Description

Don't know how long this has been around, but I just noticed it now. In Doom, holding down the right mouse button and moving around will allow you to strafe around. I set the strafe key to mouse button 2, but when I tried to move around with the mouse while the button was held down, the movement was beyond slow. My mouse sensitivity was the default, and raising it did little to speed it up. The mouse I use is a Logitech MX310, but I don't know if that has anything to do with it. Sometimes, I use the right mouse button to strafe and dodge attacks when I'm too lazy to use my keyboard configuration to do so.

Labels: Gameplay

History

#1 Updated by skyjake almost 15 years ago

This issue is caused by the (relatively) new input device code that handles device axes. The core of the issue is that since mouse axes are relative instead of absolute, they end up producing much smaller values for the strafe control.

One possible fix would be to introduce a separate sensitivity factor for strafing in this case. (A fixed factor would be sufficient to replicate the earlier behavior.)

#2 Updated by skyjake almost 15 years ago

Fixed for 1.9.0-beta6.4 using a constant sensitivity factor for relative strafing/forward movement.

#3 Updated by sonicdoommario almost 15 years ago

So is this a new feature that we'll see in beta6.4 or just an overall fix? I forgot to mention that this didn't just affect strafing, but it made overall forward/backward movement with the mouse very slow (except for turning, so I wouldn't want you to get confused with that).

#4 Updated by skyjake almost 15 years ago

It is just a fix for beta6.4. Nothing has changed except how the movement of the mouse axes (x/y) is treated for player movement (forward, backward, sideways). It is now more in line with the original behavior. No console variables were added.

Also available in: Atom PDF