AGS Mouse Sensitivity and Acceleration

[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 :'(