AGS Mouse Sensitivity and Acceleration

[Crimson Wizard]

Also, it just occurred to me, that he would have been playing my game that was compiled with AGS 3.3.3, so this must not be a new issue?

I believe this internal acceleration may be there since early years of AGS. I think it may summ up with Logitech (and similar mouses) acceleration and produce doubled effect.

Frankly, it becomes quite annoying even for common mouse when game is run in high resolution.

[Crimson Wizard]

I am interested to know if the mouse speed setting is needed, after Allegro acceleration is removed by default.
Currently mouse moves exactly like it would move on desktop, which means that user can adjust his own system settings and have appropriate effect in game.

Question: is there a reason why mouse speed setting could be useful?

Note: I would distinguish system/engine mouse speed and gameplay effect simulating slower/faster mouse movement. I believe these are two different things and should be observed separately.

[Problem]

That depends. Does the current version still have different mouse speeds for different display resolutions?
If the mouse moves exactly like on the desktop, regardless of display resolution, than a mouse speed setting isn't needed, at least not in in winsetup.exe. The possibility to change the mouse speed from the script might still be useful.

[Crimson Wizard]

That depends. Does the current version still have different mouse speeds for different display resolutions?
If the mouse moves exactly like on the desktop, regardless of display resolution,

The mouse moves exactly like on the desktop, depending on display resolution. This is how Windows works. You may easily see it by changing desktop resolution.

than a mouse speed setting isn't needed, at least not in in winsetup.exe. The possibility to change the mouse speed from the script might still be useful.

But what is the difference between winsetup and script? Is there a realistic scenario when you do not need to adjust mouse speed in setup, but still need to do so from script?


E: To clarify, it is not a problem for me to add speed setting, because the code is ready. I am wondering if it will become a redundant feature.

EE: I would also like to get reports from Linux users.

[Problem]

The mouse works very well in Linux for me, but it always did. It seems the acceleration problems only affected Windows, and in Linux it works exactly as before.

Changing mouse sensitivity from the script allows developers to add a mouse sensitivity slider in the game. This has the benefit that if you change the slider, you immediately see the result and can make quick adjustments - instead of leaving the game, starting winsetup, changing the settings, starting the game again etc.

And since you never know if the game will run in a different resolution than the windows desktop, it's of course a good idea to be able to change the mouse speed, because the mouse movement will sometimes be different than on the desktop. So in my opinion it's best to change the mouse speed from inside the game. For Rogue State, if I had both, I'd implement a mouse speed slider in the game's settings menu and ignore what is in winsetup (which is only available for Windows anyway).

[Snarky]

Yeah, I think a game is a bit different from when you're running Windows in a different resolution, because you're not deliberately changing any settings for how your computer should operate, just temporarily running a game that happens to have a lower resolution. It would be annoying to always have to adjust it before and after you play. And as mentioned, if you could change it from in-game you could offer a slider, and then people wouldn't have to quit-and-adjust-and-restart-and-test-and-quit-and-adjust... until they get it right.

Oh, and ideally these should be two separate settings: AGS should first "cancel out" the change in resolution, and then allow users to adjust on top of that. That way, if you run the game with a different filter next time, you won't also have to change all your mouse settings.

[Crimson Wizard]

I was already trying to do this thing, but I stumbled at the problem of deducing the scale "zero". Is it always maximal supported monitor resolution? I have no idea how Windows defines this. If I am to scale mouse speed up or down, I need to know what resolution to use as a base, which will have speed factor "1".
And does Linux behave the same?

E: Problem is that current mouse speed setting in AGS is not an absolute setting, but relative one, it is relative to system mouse movement.
I doubt this situation has a good solution unless the mouse speed setting would be absolute.

[Snarky]

Can't you check when AGS starts, before it changes the screen resolution, what the current resolution is?

[Crimson Wizard]

Can't you check when AGS starts, before it changes the screen resolution, what the current resolution is?

But that does not mean anything, user settings do not define the rule for system behavior. What if he changed the desktop resolution to something else? This is not a proper way to deduce the "base" resolution.
And as soon as fullscreen mode is set, it is different resolution, and system mouse has different relative speed (relative to screen).

[Crimson Wizard]

I think I would need to do a research before I can implement uniform relative movement. I will need to keep other systems in mind too (Linux at least), because they may have this working differently.
I want to add these changes now, because the behavior certainly did not become worse than it was, so it won't hurt anyone more than it already had, I guess.

The speed difference is pretty noticeable when you shift from running in 320x200 to 1920x1080, but it is not so noticeable if you change e.g. between x3 scaling filter and x4.

[Snarky]

I'm afraid I don't understand at all. First of all, if turning off the Allegro adjustment fixes the problem some people were having, that by itself is a big improvement, and the mouse speedup when games are running in low resolutions is probably something we can live with for now: it's not an urgent problem.

But that does not mean anything, user settings do not define the rule for system behavior. What if he changed the desktop resolution to something else? This is not a proper way to deduce the "base" resolution.

... isn't it? Maybe we're not talking about the same thing. What I had in mind was this:

• The user is running the desktop in e.g. 1920x1080, and is presumably happy with the mouse sensitivity they're experiencing
  
• The user launches an AGS game that is 320x200 natively, with a 2x filter, in fullscreen
  
• AGS detects the desktop resolution as 1920x1080, and figures out which resolution to change to in order to run the game (640x400)
  
• Once the new resolution has been successfully set, AGS calculates the ratio between the two resolutions (3:1 horizontally and 2.7:1 vertically). Assuming the video card/monitor fills the screen vertically and use side-bars, pixels will be 2.7 times as big in the game as in desktop mode
  
• AGS adds a modifier to the mouse sensitivity, dividing every movement by 2.7. So a movement that would have moved the cursor 1080 pixels before now moves it only 200 pixels
  
• The user therefore experiences the same relative mouse sensitivity as in desktop mode: the mouse movement needed to move the cursor a similar distance across the screen remains the same
  And isn't that exactly what we want? Obviously if you're not running fullscreen, you shouldn't be messing with mouse behavior at all. And certainly the behavior on Linux and other platforms (potentially even other versions of Windows) needs to be researched. Possibly there should be an "advanced" config setting to turn off the behavior.

[Snarky]

Oh, BTW, I just realized: I've always had a problem with the scroll wheel being crazy unresponsive in AGS games. Could that have something to do with this Allegro setting? (I'll test the new build when I'm on a PC.) If so, make sure that any adjustment only affects mouse movement, not scrolling.

[Crimson Wizard]

... isn't it? Maybe we're not talking about the same thing. What I had in mind was this:

Yes, what you say makes sense. I guess the way players look at this is more simple. For me it is not an "ultimate" solution, because that would mean that mouse speed will depend on which resolution the game was started in.
But I guess I could add such option for now.
For windowed mode it would not have any effect anyway, because it is display mode that matters, not window size; and display mode stays the same as desktop when you run game in window.

Oh, BTW, I just realized: I've always had a problem with the scroll wheel being crazy unresponsive in AGS games. Could that have something to do with this Allegro setting? (I'll test the new build when I'm on a PC.) If so, make sure that any adjustment only affects mouse movement, not scrolling.

No, it has nothing to do with that.

[Crimson Wizard]

New builds with supposedly uniform mouse speed:

http://www.mediafire.com/download/a83jl3qivbcbahu/AGS-3.3.5--mousespeed.zip
http://www.mediafire.com/download/l3ubc0hh9j2t7wx/AGS-3.4.0.7--mousespeed.zip


Note, I am changing "sensitivity" to "speed" everywhere, because this is more correct in our case.
So, the config settings are now:

Code: text

[mouse]
speed = 1.0
speed_x = 1.0
speed_y = 1.0

Also new script commands:

Code: ags

struct Mouse
{
  /// Sets mouse speed parameters
  import static void SetSpeed(float x, float y);
  /// Gets/sets whether the user-defined factors are applied to mouse movement
  import static attribute bool ControlEnabled;
  /// Gets/sets the mouse lock-to-window state
  import static attribute bool LockedToWindow;
  /// Gets/sets the mouse speed on X-axis
  import static attribute float SpeedX;
  /// Gets/sets the mouse speed on Y-axis
  import static attribute float SpeedY;
}

Code: ags

struct System
{
  /// Gets whether the game window has input focus
  readonly import static attribute bool HasInputFocus;
}

[Dualnames]

Alright, guys, run a test with the device that had the problem, successfully re-replicated the issue with current AGS 3.3.4.2 (I think) and this one fixes it. Kudos <3 Will run more tests to see general behavior, but at least the issue with erratic mouse has been resolved.

[Crimson Wizard]

Alright, guys, run a test with the device that had the problem, successfully re-replicated the issue with current AGS 3.3.4.2 (I think) and this one fixes it. Kudos <3 Will run more tests to see general behavior, but at least the issue with erratic mouse has been resolved.

Well, that is a relief .

[Crimson Wizard]

Slightly upgraded version, now has a Mouse speed slider in WinSetup and also saves new speed setting to config file on game quit if it was changed from script:
https://www.dropbox.com/s/0rc5qw57wkrn1th/acwin_3.3.5-mouse-sens.zip?dl=0

I would like to know if you will find it useable.

Known issues: game can save new value incorrectly if it was not present in config file before. This is yet again fail of  Allegro (*cough cough*) which cannot always parse config file properly. I will need to put better INI parser into AGS.

[morganw]

Slightly upgraded version, now has a Mouse speed slider in WinSetup and also saves new speed setting to config file on game quit if it was changed from script

I don't think it's safe to assume that the config file will be writable from the game process. If content is installed into Program Files by an installer, the game process (running without admin elevation) won't have permission to write the setting back.

[Crimson Wizard]

Slightly upgraded version, now has a Mouse speed slider in WinSetup and also saves new speed setting to config file on game quit if it was changed from script

I don't think it's safe to assume that the config file will be writable from the game process. If content is installed into Program Files by an installer, the game process (running without admin elevation) won't have permission to write the setting back.

Of course, same refers to winsetup program. That is why I will be moving its location to user documents.

[morganw]

This might be the wrong place to discuss it (apologies if so) but I would have thought local appdata is the most appropriate place for the config file. The configuration will be a user preference but may be computer specific because it contains the scaling and mouse speed options.