Mouse wheel speed control sensitivity

[Paladin Tux]

Hey guys

Firstly, thanks for adding this new function, really cool. However, it takes 16 scrolls to move from full to no thrust. Maybe I have a weird play style, constantly speeding up and down, or my mouse is horrible, but is there a setting somewhere which I can change, to make the scroll wheel more sensitive in game? (In game only, I don’t need a system wide change which makes me scroll to the bottom of my seventy page assignment when I move the scroll wheel 2 millimetres.)

Thanks in advance

[another_commander]

Afraid not. We do not process the mouse wheel delta at the moment, so it basically works as if pressing a key. I am pretty sure it can be fixed though, just need to find some time to play with this (I think hoqllnq already has a solution for it on the Mac, need to find the equivalent solution for Win and Lin).

[Anonymissimus]

Ha. This works so-so:

Code: Select all

diff --git a/src/Core/Entities/PlayerEntityControls.m b/src/Core/Entities/PlayerEntityControls.m
index b9e0c4e..4bc93fc 100644
--- a/src/Core/Entities/PlayerEntityControls.m
+++ b/src/Core/Entities/PlayerEntityControls.m
@@ -912,20 +912,37 @@ static NSTimeInterval	time_last_frame;
 				// DJS: Thrust can be an axis or a button. Axis takes precidence.
 				double reqSpeed=[stickHandler getAxisState: AXIS_THRUST];
 				// Updated DJS original code to fix BUG #17482 - (Getafix 2010/09/13)
+				double MouseSpeedFactor = 5;
+				BOOL MouseIncreaseSpeed = (mouse_control_on)&&([gameView mouseWheelState] == gvMouseWheelUp) && !([UNIVERSE viewDirection] && [gameView isCapsLockOn]);
 				if (([gameView isDown:key_increase_speed] ||
 						joyButtonState[BUTTON_INCTHRUST] ||
-						((mouse_control_on)&&([gameView mouseWheelState] == gvMouseWheelUp) && !([UNIVERSE viewDirection] && [gameView isCapsLockOn])))
+						MouseIncreaseSpeed)
 					&& (flightSpeed < maxFlightSpeed) && (!afterburner_engaged))
 				{
-					flightSpeed += speed_delta * delta_t;
+					if(MouseIncreaseSpeed)
+					{
+						flightSpeed += (speed_delta * MouseSpeedFactor) * delta_t;
+					}
+					else
+					{
+						flightSpeed += speed_delta * delta_t;
+					}
 				}
 				
+				BOOL MouseDecreaseSpeed = ((mouse_control_on)&&([gameView mouseWheelState] == gvMouseWheelDown) && !([UNIVERSE viewDirection] && [gameView isCapsLockOn]));
 				if (([gameView isDown:key_decrease_speed] ||
 						joyButtonState[BUTTON_DECTHRUST] ||
-						((mouse_control_on)&&([gameView mouseWheelState] == gvMouseWheelDown) && !([UNIVERSE viewDirection] && [gameView isCapsLockOn])))
+						MouseDecreaseSpeed)
 					&& (!afterburner_engaged))
 				{
-					flightSpeed -= speed_delta * delta_t;	
+					if(MouseDecreaseSpeed)
+					{
+						flightSpeed -= (speed_delta * MouseSpeedFactor) * delta_t;
+					}
+					else
+					{
+						flightSpeed -= speed_delta * delta_t;
+					}
 					// ** tgape ** - decrease obviously means no hyperspeed
 					hyperspeed_engaged = NO;
 				}

You need to apply this git patch to the 1.86 branch, likely adjust the MouseSpeedFactor to suit your ship/system settings/mouse, and build the game.

[another_commander]

I have managed to get the mousewheel delta working on Windows, but I am not sure how portable that will be. I had to make changes to SDL.dll in order to achieve this result, which means that similar changes to the library will have to be made Linux-side and the game should be fed the wheel delta information in the same way as it was done for Windows.

Maybe Anonymissimus' way could be an easier to implement solution (and more cross-platform too, although obviously not as good as proper wheel delta handling), with a little modification: rather than hard-coding a MouseSpeedFactor, we could maybe make it a .GNUstepDefaults setting, so there would be no need to recompile the game in order to change it.

[Anonymissimus]

I had to make changes to SDL.dll

Regardless of portability, this looks IMHO like a too expensive thing to do. It means the dev team has to maintain an own project-specific version of SDL. Once you want to upgrade to SDL2 or similar you have big problem.
EDIT
Linux-side modification to SDL is not possible in this manner, unless you include SDL in the oolite git repository and set up the build process to use it, see above. The dependency for compilation (libsdl1.2-dev) is downloaded from the distribution's repositories when setting up the build environment (on Ubuntu). I suppose the windows build package includes the SDL code ?!

My code above is hack-ish. A better solution should probably pre-modify the delta_t passed to that function. I guess that's what you tried.

A similar problem exists for how mouse movement translates into roll/pitch/yaw btw., which is also not configurable, and which I solved by modifying the
#define MOUSEVIRTUALSTICKSENSITIVITYFACTOR
This could be a similar configurable option.

[another_commander]

I had to make changes to SDL.dll

Regardless of portability, this looks IMHO like a too expensive thing to do. It means the dev team has to maintain an own project-specific version of SDL. Once you want to upgrade to SDL2 or similar you have big problem.

We have been maintaining our own SDL on Windows since about 2007. Time and again, being able to make direct changes to the library without having to wait for upstream to apply fixes or be compatible with what we wanted to do, has proven invaluable. As for SDL2 migration, problems are expected no matter what; it is never a completely smooth transition. Actually, the SDL2 migration attempt that had been started a while ago on github as a pull request by an external collaborator seems to have stalled early so I don't think we'll be upgrading any time soon.

[another_commander]

In case there is interest in testing the new mousewheel handling on Windows, here is the link containing the new SDL.dll and the game exe that uses it (64-bit, 1.87 trunk): https://drive.google.com/open?id=1bxq7Y ... AIYFxkwQ5Y

[another_commander]

Mousewheel handling adjusted to match original post request. It will be in for tomorrow's nightly.

[Anonymissimus]

I have just upgraded to the 1.88 branch and recompiled. I don't notice much of a difference (if any) regarding the "speed change by mouse wheel" feature albeit I skipped my patch from above. So, that's good. For me at least.
Are there settings configurable without compiling now ?

[another_commander]

The difference is felt when you try to move the wheel very fast up or down. While previously you would need many moves of the wheel to reach top speed, you can now do so with a couple moves, or even one move, if you do it fast enough. Same for reducing speed.

I am not sure I understand the question. Which settings exactly do you refer to?

[Anonymissimus]

I am not sure I understand the question. Which settings exactly do you refer to?

rather than hard-coding a MouseSpeedFactor, we could maybe make it a .GNUstepDefaults setting, so there would be no need to recompile the game in order to change it.

Any setting in some configuration file and/or command line parameter, basically.
In case that someone else's mouse sends less or more ticks per turned angle than mine or so.

[another_commander]

Ah OK. No, this has not been implemented yet.