Project

General

Profile

Bug #1009

[Controls] Mouse for walk/sidestep is unbalanced

Added by skyjake over 12 years ago. Updated about 12 years ago.

Status:
Closed
Priority:
High
Assignee:
Category:
-
Target version:
Start date:
2012-03-16
% Done:

100%


Description

I use the mouse for moving as with the original vanilla Doom. If I walk backwards by moving the mouse it feels the autorun is constantly on. When strafing to the left it goes much faster than strafing to the right.

The measurable thing is that if I put the mouse between two large books (so that the mouse can move only a standardized distance forwards and backwards), and if I walk very-very-slowly the player walks the same distance both forwards and backwards.

But if I walk any faster (the normal speed) the player easily walks backwards twice the distance than when walking forwards. The same thing with strafing left or right. It's almost like the mouse doesn't register all the movements to the every direction.

This can be tested for example in the vast outdoor area in Doom E1M8. My fps reading is all the time at 125.0, so it's not a system speed issue.

This problem doesn't occure with other games or any other Doom ports (Vavoom is a bit stiff) and this is not a new thing, it has been with the previous 1.90 betas I've tried.

The system should be up to date. I've tried this with three different computers (winXP, Vista) and with different mouse (Logitch, MS, Compaq, all standard mouse with two buttons + one wheel button).

Switching autorun ON, or input-mouse-y-scale:0 (and strafe-skating all the time) do help but they require quite different style.

bingings are:
walk forward: mouse+y
walk backwards: mouse-y
turn left: mouse-x
turn right: mouse-x
input-mouse-x-scale: 0.0015 (default: 0.001)
input-mouse-y-scale: 0.0015 (default: 0.001)

Setting different values (0-30) to input-mouse-filter have no improvement.

Labels: Controllers

History

#2 Updated by skyjake over 12 years ago

This was occurring because the Walk and Sidestep controls weren't properly clamped to -1..1 range (instead was much larger than that), causing inconsistent results.

Also available in: Atom PDF