AGS Mouse Sensitivity and Acceleration

[xil]

I've been doing a few tests on various devices as I've recently made a super low res game (160x90 in the new alpha 3.4.0.3) and have had issues with the mouse movement in fullscreen. No matter what settings I play with and what hardware I use, there still seems to be something off with the mouse movement (I'm not sure if anything was ever even addressed as the other topics just seemed to fizzle out months/years ago).

All tests have been windows 7 based using the following equipment:

• a laptop (running at 1366x768) using the track pad
• a laptop (running at 1366x768) using a default cheap mouse with no drivers
• a desktop PC (running at 1080p) using a high end razer gaming mouse (razer synapse drivers - similar to logitech and set point I imagine)
• a desktop PC (running at 720p) using a default cheap mouse with no drivers

I've used pretty much all of the combinations of settings to scale the game when in fullscreen and all act the same.

The best fullscreen mouse movement seems to be split between the laptop using the track pad and the desktop PC 720p with default mouse no drivers. The worse movement is on my desktop PC with the razer mouse tweaked for optimal FPS settings (high DPI, polling rate etc).

However, in every single case, no matter what tech or drivers, there is definitely mouse acceleration present (I play a lot of FPS games so I know when my mouse doesn't feel right). It ranges from barely noticeable to horribly evident and unusable. My problem is that whatever settings I set my razer mouse/windows settings to (0 acceleration everywhere possible) it is still present when running fullscreen in the AGS engine.

I can live with no settings to change sensitivity in game as it's trivial to set my mouse speed to whatever works with the game (sensitivity options for the user would be perfect, but not needed).

But why does AGS apply acceleration seemingly hard wired in?

[Crimson Wizard]

After some research I found that the mouse acceleration parameter for fullscreen mode is set up inside Allegro library using some curious formulae, where screen metrics are input parameters.

Code: cpp

/* mouse_directx_set_range: [primary thread]
 */
static void mouse_directx_set_range(int x1, int y1, int x2, int y2)
{
   <...>

   /* scale up the acceleration multiplier to the range */
   mouse_accel_mult = mouse_accel_fact * MAX(x2-x1+1, y2-y1+1)/320;
}

By tweaking that code I could find a value that worked well for me... (it was "mouse_accel_mult = 2;" or "3", while formulae gave result of "5")

I also could find that "mouse_accel_fact" parameter can be read from config file, but only using built-in Allegro config system (which AGS does not use, it seems); nevertheless, using this parameter alone does not allow me to set the fine speed: value "1" is faster, and value "0" is too slow.

(these params should be real numbers instead of integers )

This should be researched some more... but I guess I should either modify the formulae, or just allow AGS get deep into Allegro internals and set this value from its own config.

[Dualnames]

As this have been trackered by me, a month ago or so, from what I gathered is that AGS grabs the x and y directly from the input given from the mouse device. Thus acceleration done by software will always mess things up. For some weird reason, when on fullscreen, the mouse behaves a bit weird, barely noticeable, but still there.

http://www.adventuregamestudio.co.uk/forums/index.php?topic=51548.msg636504981#msg636504981

I even tried some sort of software acceleration hoping that the allowance of mouse speed alteration via software would fix the issue, but to no avail.

Digging deeper into this, I did find out that Allegro allows the setting of the mouse-speed, but i believe even with the mouse sensitivity option existing, the issue remains elsewhere. As far as I could tell, AGS is using Allegro to get the X,Y of the mouse and then assigns a sprite to the cursor, and then sets the X,Y pos somewhere else, for some reason, I couldn't tell myself, the issue is terribly annoying on full screen.

I'm prolly talking non-sense.

[xil]

Hi, sorry Dualnames, I was searching for mouse acceleration so missed your post.

I've tried the code you posted but didn't have much luck I'm afraid (the code that monkey_05_06 modified unfortunately didn't help either, if anything it was worse).

Crimson Wizard, the screen metrics being input parameters seems interesting as my tests do indicate that the problem is less evident the higher the resolution of the game but I have even tested a full 1920x1080 game running and the mouse acceleration makes the game (for me anyway) unplayable. If I needed to do any sort of precision movement within say 100 pixels then it's OK but if I need to just move around the screen it accelerates beyond control.

When you talk about the value 0 for mouse_accel_fact being too slow, what do you mean exactly? Does it feel like acceleration is off, but the mouse speed is stupidly slow? I'm afraid my knowledge of allegro and windows programming in general is very limited.

Does it not differ between accelerating the mouse and the speed of the mouse? E.g. I would expect as a user that if the acceleration was turned off and my mouse speed was very low, I'd just hop into the settings and increase the mouse speed to suit.

[Crimson Wizard]

When you talk about the value 0 for mouse_accel_fact being too slow, what do you mean exactly? Does it feel like acceleration is off, but the mouse speed is stupidly slow?

Well, it is stupidly slow. Like 10 times more slow than the windows cursor (speaking of feelings here, I did not actually make any measures).


I cannot answer other questions yet. My previous post was just a quick note.
I am searching through Allegro forums now to see what they say about this problem.

[xil]

Yea it could be stupidly slow because the engine was set up by default to have a medium amount of acceleration. If that was always on by default then in theory I understand  why the mouse speed would be hardwired so low.

Thanks for having a look anyway, hopefully the stupidly slow mouse speed was due to eliminating acceleration and now it's just a case of upping the speed in another way.

[xil]

Quick update, I found a forum post from a user stating that allegro 4 has issues with fullscreen mouse acceleration and that allegro 5.0.5 'fixed' the issue. I say 'fixed' as he states: "i had to port my infinite perlin noise terrain generator to allegro 5.0.5 to get the mouse to work in fullscreen without annoying excessive acceleration." - so it might just be useable rather than removed.

[Crimson Wizard]

Well, Allegro 5 code is in numerous ways not compatible with Allegro 4. I will check the lib sources to see how they solved it though.

Regardless, I would not like to change anything in libraries, unless there's just no other way.
I am currently interested in testing out another solution I found, using get_mouse_mickeys function. If I use it instead of just getting x,y coords Allegro provided me with, I could override its acceleration mechanics. If that actually works, this solution would have such benefit as 1) portability, 2) easier implementing user setup.

[Knox]

With all of this being potentially "fixed", would it be then possible in the future for the player being able to tweak mouse sensitivity/acceleration to his/her liking in the game settings as well?

[Crimson Wizard]

With all of this being potentially "fixed", would it be then possible in the future for the player being able to tweak mouse sensitivity/acceleration to his/her liking in the game settings as well?

Yes.

[Dualnames]

Keep us posted then! <3

[Crimson Wizard]

I am currently interested in testing out another solution I found, using get_mouse_mickeys function.

Well, I must point out that this will work in fullscreen mode only.
Allegro does not let me control mouse position outside of the window, therefore I can't know actual cursor coordinates on screen, can't even know when mouse left the game window. Since I keep adjusting cursor position, mouse can't leave the window at all.
For sensivity to work in windowed mode I would need to descend to OS API mouse functions.

[selmiak]

get_mouse_mickeys function.

[Snarky]

Well, I must point out that this will work in fullscreen mode only.
Allegro does not let me control mouse position outside of the window, therefore I can't know actual cursor coordinates on screen, can't even know when mouse left the game window. Since I keep adjusting cursor position, mouse can't leave the window at all.
For sensivity to work in windowed mode I would need to descend to OS API mouse functions.

That sounds fine to me. In Windowed mode I would normally expect the cursor to move uniformly across the screen according to the Windows sensitivity/acceleration settings, whether or not it's on top of the AGS window.

[xil]

I am currently interested in testing out another solution I found, using get_mouse_mickeys function.

Well, I must point out that this will work in fullscreen mode only.
Allegro does not let me control mouse position outside of the window, therefore I can't know actual cursor coordinates on screen, can't even know when mouse left the game window. Since I keep adjusting cursor position, mouse can't leave the window at all.
For sensivity to work in windowed mode I would need to descend to OS API mouse functions.

I second that that would be absolutely fine. Id hesitate to say that's exactly how it should work anyway.

[Crimson Wizard]

Hmm, I actually found a way to have it working on windowed mode too. Basically, custom sensivity ony works when the cursor is in the game boundaries.

Here I made a test build:
http://www.mediafire.com/download/gtjbfbo0p2407ki/acwin_3.4.0.3_mouse-sens.zip

Setup parameters to be added to acsetup.cfg:

Code: text

[mouse]
ags_control = 1 // to enable AGS sensivity management
sensivity = 1.0 // overall sensivity (floating point value)
sensivity_x = 1.0 // optional separate sensivity for x
sensivity_y = 1.0 // optional separate sensivity for y

[xil]

Hi CW,

Thanks for putting together that test build. I've had a little play around but will get you some proper tests on different setups done hopefully in the next couple of days.

Unfortunately the only test I've managed to do (using my gaming mouse with stupidly high DPI and custom drivers e.g. the stuff that seems to mimic the Logitech Setpoint issues) hasn't worked 100%. The actual changes do have an effect and I can now control the sensitivity but there is still a point at which acceleration is applied and I lose control of the mouse.

Good part of the test:

• the ability to control the mouse by moving it carefully is MASSIVELY improved, literally to the point where it would be playable
• works great in windowed mode!

Bad part of the test:

• the mouse can go "out of bounds" and you have to carefully bring it back to gain control of the pointer image again
• it's possible to almost completely "lose" the mouse as there just seems to be no bounds anymore

On a side note, I might be being stupid but are the setup commands spelled incorrectly?
sensivity = 1.0 // overall sensivity (floating point value)
sensitivity = 1.0 // overall sensitivity (floating point value)

[Crimson Wizard]

the mouse can go "out of bounds" and you have to carefully bring it back to gain control of the pointer image again

Well, this is essential for the windowed mode. I do not want to bring much technical details here, but in short, when mouse has left the window I loose the ability to know its proper coordinates and cannot control its position beyond the window (at least not with Allegro library); all I can do is getting the deltas of its movement, so I would know when it returns back. If I would alter its position as I do in game bounds, I would lock it inside game, so player would need to Alt+Tab to get to his/her desktop.
OTOH, that may be the way to do this?
E: Hmm, maybe you are speaking about black borders? I might have made a mistake there, letting mouse "loose" too early. I should do this when the mouse has left the window, not the game borders.

it's possible to almost completely "lose" the mouse as there just seems to be no bounds anymore

Can you elaborate how this happens?

On a side note, I might be being stupid but are the setup commands spelled incorrectly?
sensivity = 1.0 // overall sensivity (floating point value)
sensitivity = 1.0 // overall sensitivity (floating point value)

Umm... yeah, that is my bad english.

[Snarky]

I think xil was talking about the mouse going out of bounds in fullscreen mode?

I still think that in windowed mode you should just leave the mouse alone and let windows handle it. As a user, I don't expect the mouse movement to change depending on what window it's over.

[Crimson Wizard]

I fixed some mistakes, here is a new build for test:
http://www.mediafire.com/download/gtjbfbo0p2407ki/acwin_3.4.0.3_mouse-sens.zip

The options now are:

Code: text

[mouse]
control = always | never | fullscreen // mouse control kind
sensitivity = 1.0 // overall sensitivity (floating point value)
sensitivity_x = 1.0 // optional separate sensitivity for x
sensitivity_y = 1.0 // optional separate sensitivity for y

[Crimson Wizard]

Here is another test build, now combined with ability to lock mouse cursor in window (use with discretion! unlike SetBounds that will actually not let mouse leave the window borders, thus only way to click elsewhere is to do Alt+TAB).

http://www.mediafire.com/download/rkc1sddkdar0d7l/acwin_3.4.0.3_mouse-lock.zip

New script properties:

Code: ags

bool Mouse.LockedToWindow;

bool Mouse.ControlSensitivity;
float Mouse.Sensitivity; // actually returns SensitivityX when being read
float Mouse.SensitivityX;
float Mouse.SensitivityY;

I also found an unintentional feature of being able to "invert" cursor movement when sensitivity is negative .

EDIT: I think I may prune API by removing Mouse.Sensitivity property actually.

[monkey0506]

I think a "SetSensitivity(x, y)" function would make more sense than a property in that case (similar to SetSize method for GUIs). Still allow setting them separately, but use the two parameter method for setting both at once.

And nice job with the inversion feature! Kind of kitschy, but I can't see it being misused, abused, or causing confusion, so why not?

[Dualnames]

A million thumbs up, these are great news!

[Crimson Wizard]

And nice job with the inversion feature! Kind of kitschy, but I can't see it being misused, abused, or causing confusion, so why not?

I decided to remove that; the thing is that the "inverted mouse" is a separate feature, not directly related to sensitivity, and if sensitivity control is off (e.g. default in windowed mode) it simply won't work.
If wanted, we may add something like Mouse.InvertX and Mouse.InvertY flags later.

[Crimson Wizard]

A new build:
http://www.mediafire.com/download/4s9won68w7p6g4h/AGS-3.4.0.4-mousefeat-.zip

1. Replaced Mouse.Sensitivity property with Mouse.SetSensitivity(x, y);
2. Negative sensitivity no longer works (will be changed to zero).
3. The new property System.HasInputFocus tells if the user switched from the game window. Since the game can run in Multitask mode, this might be helpful e.g. if you are changing mouse position in repeatable_execute.

Spoiler

Code: ags

int ticks;
function repeatedly_execute_always()
{
    if (System.HasInputFocus)
        ticks++;
    lblLabel1.Text = String.Format("Was away for: %d ticks", ticks);
}

[close]

[Crimson Wizard]

So, Dualnames just told me that this works well for him. Was anyone else (who was having troubles with mouse) able to try this out?

[xil]

Hi CW, really sorry it's taken me this long to test it!

The changes and new commands are all functioning perfectly, however, it does still seem to retain some acceleration I'm afraid.

It's almost perfect on a standard mouse but with the high DPI mouse the user must be very careful when moving around. If you move the mouse suddenly then the acceleration kicks in and takes it way off course.

Everything is now staying in bounds though so it's certainly much more useable than the current stable build.

[Knox]

Hi Crimson,

I downloaded this version to test the new mouse sensitivity feature, however I'm getting a compilation error related to set/get custom properties that I wasn't getting in 3.4.0.3 Alpha:

Containers & ItemQuantities_ACL.asc(690): Error (line 690): Type mismatch: cannot convert 'void' to 'bool'

Code: ags

bEx = this.SetProperty("Expanded?",1);

I'm guessing the get/set custom properties feature has now been re-implemented into this version? I tried using "true" instead of "1" in the line above but I still get that error (or removing the "1" but then its says I don't have enough parameters for the function).

PS: I removed the old CustomProperties Helper plugin from my game to be sure (and removed the ags_customproperties.dll from all related ags/game folders) http://www.adventuregamestudio.co.uk/forums/index.php?topic=42446.msg563322#msg563322

What should I do next to get it to compile?

Edit: (Once I can get it running I can give some feedback on the mouse sensitivity feature)

[Crimson Wizard]

In 3.4.0 SetProperty is a "void" function, meaning it does not return anything. You can't assign its return value to a variable.

The readme for CustomProperties plugin tell that their functions "returns true on success, false otherwise".
This seem to be better handling of possible errors than AGS has, so I might change my functions to bool too.

For now you may fix by doing this:

Code: ags

/* bEx = */ this.SetProperty("Expanded?",1);

but I am afraid it will take you some time to do. Also that may break your scripts logic. So better just wait, or use other project to test.

[Knox]

Ok I will see if I can get rid of the bEx bool by just checking the GetProperty value is 1 or 0 or something. What are the chances you decide to change your functions to bool?

In the meantime I'll use some other project to test the mouse sensitivity. Thanks for the info!

EDIT: Yeah, I don't know how I'll be able to use get/set properties if they don't return true/false...its really "spaghettied" into my whole game logic...

[Crimson Wizard]

The changes and new commands are all functioning perfectly, however, it does still seem to retain some acceleration I'm afraid.

It's almost perfect on a standard mouse but with the high DPI mouse the user must be very careful when moving around. If you move the mouse suddenly then the acceleration kicks in and takes it way off course.

But the main reason I was adding this is to let a workaround for non-standard mouses. What could be the solution here?

Everything is now staying in bounds though so it's certainly much more useable than the current stable build.

I don't understand, what "bounds" you mean, can you elaborate please?

[xil]

But the main reason I was adding this is to let a workaround for non-standard mouses. What could be the solution here?

Well I'm really at a loss as it's just an extremely strange mouse movement - I have never experienced it in any game I have ever played. Unfortunately I'm also not a good enough programmer to tell you if it's simply the engine you are working with or something in your own code, however, something does tell me it's an underlying problem.

You have improved it, there is no doubt about that, but there is still acceleration present when you move the mouse more suddenly. If that is something that is hard coded into Allegro then perhaps the best idea is to wait and see if we go down the Allegro 5 route, and hope that we can sort the issue that way.

The only way I know how to explain it is to reference what an FPS player would call a 'twitch' movement. Moving the mouse around the screen at a constant smooth speed it functions 100% normally, however, if I were to move very quickly say 30 pixels from left to right, my mouse is not where I expect it to be (or where it would be if I did the same movement in windowed mode), it ends up 120 pixels to the right due to acceleration kicking in.

I don't understand, what "bounds" you mean, can you elaborate please?

I was merely comparing to the last version I tested in which the mouse in fullscreen could leave the screen edges. I think you fixed it a while back so now the mouse is always on screen no matter how much you drag it left, right etc. That was just a fullscreen issue and like I say I think it was a slight error in the code and you swiftly sorted it.

Would you like me to do a screen capture of a test game so you can see the issue in real-time?

[Crimson Wizard]

Would you like me to do a screen capture of a test game so you can see the issue in real-time?

Yes, that would be nice.

[xil]

Hi CW,

I'm having a lot of issues getting a screen capture as they only seem to capture in windowed mode.

I had one other possible idea but it might be a huge task.

There was a post saying that someone ported their project to allegro 5.0.5:

is ta3d using allegro 4? the mouse has the same acceleration in fullscreen as allegro 4. i had to port my infinite perlin noise terrain generator to allegro 5.0.5 to get the mouse to work in fullscreen without annoying excessive acceleration.

Is it a horribly long task to compile a 'game' using allegro 5.0.5 where it's simply a black screen and a white mouse pointer. I could then run this 'game' and determine whether or not allegro 5.0.5 makes any difference?

The only reason I suggest that is because there was some talk about possibly porting over to allegro 5.

[Crimson Wizard]

Is it a horribly long task to compile a 'game' using allegro 5.0.5 where it's simply a black screen and a white mouse pointer. I could then run this 'game' and determine whether or not allegro 5.0.5 makes any difference?

The only reason I suggest that is because there was some talk about possibly porting over to allegro 5.

Not AGS game. Porting AGS engine to Allegro 5 may take months.
One could write a simple program based on Allegro 5 that only draws a cursor over black screen. That's couple hours of work.

[xil]

Not AGS game. Porting AGS engine to Allegro 5 may take months.
One could write a simple program based on Allegro 5 that only draws a cursor over black screen. That's couple hours of work.

Oh yes, of course, I meant 'game' in the loosest of senses - as bare bones as possible just to test the mouse cursor movement. I've been searching but there really doesn't seem to be much more help on the forums. Someone was saying that DInput applies its own acceleration and it also depends on systems and possibly other drivers so it sounds like a nightmare thing to debug.

But, I remember we had some discussion about this in the past, and it seems that DInput (or the mouse driver itself) does its own acceleration (on some systems/drivers, not on others).

Perhaps if the Allegro 5 port goes ahead then we can look at doing the bare bones test to see if it does indeed sort the issue. I think for now I might just put a warning on all my games to let the user know that running in a window is the best option if they have any issues with the mouse in fullscreen. Users seem pretty open to simple fixes like this when games are free and/or made for a game jam etc.

The issue must be a worse one for people like WadgetEye, although it would be interesting to know what percentage of their support questions revolve around mouse issues. It's it is very low then I really don't see the point of spending your time doing much more. Like I've said before you have already improved it to a point where it is now playable from before when it was completely unplayable and un-configurable, so I'm very happy in that regards.

[Crimson Wizard]

I am terribly sorry for this delay. I could not make myself work on AGS in the past month or so for some reasons. I will try now.

I made a new test build, it has 2 differences:
a) There is now a mouse sensitivity setting in the winsetup dialog.
b) By Knox's request I changed SetProperty function return value to bool to match the existing plugin.

https://www.dropbox.com/s/1opin0ok2c1kywp/AGS-3.4.0.4-mousefeat-7apr2015.zip?dl=0

I would be very grateful if someone who has an active project would try this out (having a backup copy, of course), to see if the mouse works properly if you do not change default sensitivity setting. I mean, I need to be sure that it does not screw default mouse behavior.

If there won't be any new problems, I will finally make another public release of AGS 3.4 with all these changes.

[Radiant]

That's an interesting new development.

I do believe that mouse sensitivity belongs under 'advanced' options, since the average user will have no idea what this does or what to change it to, and since it's pretty uncommon for games to have a mouse sensitivity option. Aside from that, I find that both the upper bound (10x) and the lower bound (1/100th) give silly results, so I suggest that this should probably be capped to something between 0.3 and 3.0, with increments of 0.1 instead of 0.01. Finally, it's probably clearer to express it as a percentage instead of a fraction.

HTH!

[Crimson Wizard]

What about the default behavior (sensitivity 1.0)? Does the in-game cursor feels like before?

[Gurok]

The in-game cursor feels like it did before:
- In windowed mode, it has desktop's speed & acceleration
- In full screen mode, it appears to be fine speed-wise, but has massive acceleration, like it's moving over a 320x200 section of a larger desktop and not the full 1920x1200 desktop
I ran an extensive test with sensitivity=1.0 and then tried 0.8, 0.5, 0.3 and finally 0.01
Changing sensitivity did nothing for me in either full screen or windowed mode
I'm running Windows 10 with a Corsair M95 mouse
Apologies, CW. I know this isn't a great report, but it's what happened for me :'(

[Crimson Wizard]

Yes, there is something wrong with this build, 1.0 is way too fast, 0.4 is like original version, and 0.15 is almost as fast as 0.4, and it only becomes slow when < 0.1. Or maybe it depends on game resolution and scaling. I must investigate all this more.

[Crimson Wizard]

Bumping this topic, for this issue must be solved at last.

I've spent some time investigating how mouse sensitivity is implemented in some of the open sourced software, but to be honest, I did not find anything particularly different from what I was doing (and I was hoping there is some magic formula ).

I am still not sure where the "massive acceleration" reported previously is getting from, because code-wise it should not; it should move mouse 1:1. Perhaps it will help if I add a display resolution factor, and select different base values. Another idea is to add actual mouse acceleration parameter along with sensitivity (speed). Combining these values could possibly achieve better results (e.g. setting lower sensitivity but slightly positive acceleration).

In the latter case it will also be possible to set a negative acceleration (faster you move the mouse, less is the physical:virtual relation), it would be interesting to run few experiments with that.

Also, now I am making this on 3.3 branch, if I succeed this will be added to next 3.3.5 update first.

[xil]

Thanks for giving it another go!

I think the problem you're facing is that the 'massive acceleration' only seems to affect certain mouse drivers. This makes fixing it in code a bit of an odd solution as for a lot of people it's perfectly useable.

I think opening up the values for acceleration and speed would be a great idea and I'd be happy to do some testing once OROW is over.

[Dualnames]

CW, as far as i know the issue comes from the mouse software that comes with certain mouses that uses a software acceleration.

[Crimson Wizard]

I think the problem you're facing is that the 'massive acceleration' only seems to affect certain mouse drivers. This makes fixing it in code a bit of an odd solution as for a lot of people it's perfectly useable.

Well... it kinda seems that I was fixing a wrong thing all this time. Well, maybe not generally wrong, but not the one which was critical.

How do other games cope with this? Do they all have extra acceleration too? Should this really be dealt with inside AGS, maybe it is that software that need to be adjusted instead?

E: Hypothetically, extra acceleration could be compensated with deceleration in AGS, but that is a guess.

[Snarky]

Yes, reading the updates on this issue, I've also wondered if AGS is taking the wrong approach.

I'm not well versed in the technical details here, but my general intuition is that when you're just using the mouse to move a cursor around, the mouse should under normal circumstances behave just like it would on the desktop, and that it should be up to the OS/shell to translate mouse inputs to cursor coordinates (so AGS shouldn't have to set the sensitivity or define screen borders). So I'm wondering if the mouse APIs used by AGS are too low-level. After all, e.g. FPS games that use the mouse for targeting probably need much more direct access to the mouse, so a library like Allegro might provide API calls that are more suitable for such a scenario.

Some caveats to this argument:
-Is there actually a higher-level API available? I mean, I know that when you write a windowed app you don't have to code in the mouse movement yourself, but is that available to the type of application AGS is?
-This might work well in windowed mode or if AGS could run in "pseudo-fullscreen" (scaled to the desktop resolution in an undecorated window), but how does Windows and other OSes handle mouse sensitivity/acceleration when the screen resolution changes? Is the speed in pixels scaled so that the amount of mouse movement needed to cross the screen remains the same?
-In a multi-screen environment, or if the game resolution is not the same as the screen resolution (because of borders etc), would a higher-level API allow us to elegantly keep the cursor within bounds?
-What if we want to be able to adjust these parameters in-game, or use the mouse in some other way. Would that still be possible?

[Crimson Wizard]

I cannot use any API lower than OS/shell. And I do not translate mouse inputs to coordinates, that is what OS/drivers do.
What I tried to do is to ask the library about relative cursor movements and apply additional speed factor, that could be set up by player. I thought that this would at least limit the troubles caused by accelerating mouse software, but I guess I was wrong.


The current problem is that AGS uses "high-level API" that does not work well. (Actually, I would prefer word "layer" here). It uses Allegro mouse API, but Allegro does some extra processing to mouse coords when in fullscreen mode, making it accelerate, while providing little to no control over this behavior. Even the acceleration threshold factors are hard-coded. And it does so only on Windows for some wicked reason.


BTW, I have only recently found that the way I was implementing sensitivity by getting relative mouse movement instead of absolute coords, does not override Allegro acceleration! because Allegro applies that acceleration to relative movement first.
Meaning, what I've done so far, was still bearing same problem as before.


E: There is one trick I have just found; possibly that will turn this Allegro acceleration off for good. Will try this out today.

[Crimson Wizard]

To quickly clarify some things (I intentionally do this in a separate post).

Current problems in AGS are:
1) Extra acceleration applied by Allegro library, only on Windows, and only in fullscreen. For the reasons I do not know, Allegro uses DirectInput when in fullscreen, and core Windows API when in windowed mode. Therefore the cursor behavior will be different.
I searched mouse routines for other OSes in Allegro, and they do not seem to make any difference between windowed and fullscreen mode.

2) Extra acceleration applied by "mouse software". The confusing part here, something that I do not know well enough, is when exactly this software kicks in. If it is not a driver, but a normal Windows application, then it should probably work by tracking mouse movement in Windows and set new cursor position on its own.
Question is, whether AGS should bother. The only way to counter this would be to introduce our own acceleration, or rather deceleration. But this sounds pretty... odd. Therefore, I would like to know how other games deal with this situation, and do they?

3) Do we actually need a cursor speed control in AGS? If yes, Allegro one is not precise; its speed config is integer, and lowest possible value is 1:1. If we want to open cursor speed setting to end-user, then I'd rather use our own cursor routine.

[Snarky]

Is it possible to not use Allegro for mouse input?

[Crimson Wizard]

Is it possible to not use Allegro for mouse input?

Of course, but I would need to use another cross-platform library, or write all the mouse code myself from scratch, at least for Windows and Linux.

[Crimson Wizard]

Alright! Silly me... I actually found a way to completely disable Allegro acceleration.
It appeared it reads the base acceleration factor from config file, being 1 by default, and setting it to 0 would disable acceleration completely.
Thing is that AGS never registered any config file for Allegro.

I could let Allegro read from our own config file, but I am slightly concerned of option name conflicts. Therefore I went other way and generated config text for the library at runtime (it does not create any temp files in folder, but writes text in memory).

Here's the build:
http://www.mediafire.com/download/ki1nm72bfpfa2df/acwin_3.3.5-mouse-sens.zip

This build is based on 3.3.5 version (next update to 3.3, do not confuse it with 3.4.0 !).
As with previous experimental builds, following config options works:

Code: text

[mouse]
control = never | fullscreen | always // when to control mouse movement, fullscreen is default
sensitivity = 1.0 // mouse speed, uniform one, or optionally separate for X and Y axis
sensitivity_x = 1.0
sensitivity_y = 1.0

al_win_mouse_accel_factor = 0 // to adjust Allegro's acceleration (integer values only)

I am letting to set Allegro acceleration for easier test of difference between having and not having it.
Original value is 1. Setting higher values will make acceleration extreme.

Mind, that this acceleration really works only in Windows...



A note on sensitivity. It appears my "default" mouse speed is faster from Allegro's fullscreen by factor of 2. This is because Allegro uses additional mouse input / pixel conversion, dividing mouse motion by 2. I am not sure why it is doing that.
Anyway, with sensitivity config you can return old speeds back (set sensitivity = 0.5). But I think this is too slow.
For my personal preference sensitivity = 1.5 works pretty well.

To achieve original AGS control feel:

Code: text

[mouse]
sensitivity = 0.5
al_win_mouse_accel_factor = 1

Since I've been spoiled by Microsoft's Pointer Precision, I might try adding configurable mouse acceleration later.

[Problem]

This is excellent news! So to get it straight, if I set al_win_mouse_accel_factor to 0, I do get the mouse driver acceleration like the Windows dekstop, but I don't get any additional acceleration from Allegro?

[Crimson Wizard]

This is excellent news! So to get it straight, if I set al_win_mouse_accel_factor to 0, I do get the mouse driver acceleration like the Windows dekstop, but I don't get any additional acceleration from Allegro?

You know,... I was about to tell that you do not get any acceleration from Windows desktop, but then I tested this out, and in fact you do.
Pixel Precision setting affects fullscreen AGS too!

I am still not sure whether mouse speed fully matches the desktop one. For better tests I would need to use the 3.4 branch and test mouse speeds in game running in my desktop resolution.

[Crimson Wizard]

Made test build for 3.4.0 too.

To list available ones:
* 3.3.5 with mouse sensitivity
* 3.4.0.7 with mouse sensitivity


In regards to tests: it appears that a) cursor movement is now linked to your desktop settings; b) it does not take resolution into account, which means that running with smaller display resolution makes cursor movement faster. Latter is true for both Allegro's and my code.
(Well, this is true for Windows, so...)
Allegro code has an attempt to rely on resolution, but the factor is applied only to acceleration, which we hate so much. I am going to try applying similar factor to mouse speed instead. My idea is that sensitivity "1" should feel about same way in any resolution.

[Snarky]

Great work, CW! I've never had mouse problems myself, or I'd help test it.

[Crimson Wizard]

Well, it will be good to test that it remains usable for you too.

[Problem]

I can confirm that the mouse movement is a lot better now, and that lower (display) resolutions make the mouse pointer faster.

[Michael Davis]

So to try out this latest 3.4 test build we just overwrite the acwin.exe inside our existing AGS folder? Are there any settings we need to change along with it?

[Crimson Wizard]

So to try out this latest 3.4 test build we just overwrite the acwin.exe inside our existing AGS folder? Are there any settings we need to change along with it?

You are not required to change any settings in your game project, but you may try adjusting the mouse behavior by manually modifying acsetup.cfg, as explained here: http://www.adventuregamestudio.co.uk/forums/index.php?topic=51695.msg636519799#msg636519799

In the final release there will be more convenient means to do so.

[Michael Davis]

Ha! Total coincidence, yesterday a YouTuber left a comment on my game's GameJolt page saying he had made a series of Let's Plays of it, so I started watching it today and you can see in his first episode, at around 07:15, the player "discover" the mouse acceleration bug:

https://www.youtube.com/watch?v=n_LVDkTOsAQ

He's using the mouse to scroll along some words he's reading, and the mouse cursor suddenly takes off when he hits the mouse movement speed threshold that triggers the acceleration.

So if you didn't have concrete evidence of the behaviour yet there it is. I can certainly vouch that my Logitech mouse behaves lousy in the current 3.4.0.6 alpha, in this specific way, I mean, so I'm really excited to test your latest patch! Thanks for everything you do, CW <3

edit----
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?

[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.

[Crimson Wizard]

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.

Yes, this is all yet to be considered. Let's pretend I said "some special Windows folder where program can write without admin permission".

[Dualnames]

Wonderful news, will test again as soon as possible <3

[Crimson Wizard]

I released the 3.3.5 "Beta" which has mouse speed setting and mouse lock in window implemented:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=52925.0