AGS 3.3.5 -- Release Candidate

Started by Crimson Wizard, Sat 21/11/2015 19:45:52

Previous topic - Next topic

morganw

I was seeing this problem in a window and fullscreen.

This commit introduces the problem:
https://github.com/adventuregamestudio/ags/commit/6a35ec9936b545cbb4d405309f24359fbe6e80f5

But even with a controllable cursor (reverting the above commit), something seems to off with regard to fullscreen. The cursor movement is restricted to co-ordinates which are too small, contained to the top left corner of the game. Using x2 scaling increases the area it's possible to move in, and is a closer match to the actually game resolution, but still not correct.

Crimson Wizard

#41
Quote from: morganw on Sun 06/03/2016 09:38:41
This commit introduces the problem:
https://github.com/adventuregamestudio/ags/commit/6a35ec9936b545cbb4d405309f24359fbe6e80f5

But even with a controllable cursor (reverting the above commit)
This commit is not related to cursor control, at all...
Following commit disables controllable cursor for Linux: https://github.com/adventuregamestudio/ags/commit/98f9c963757b438c01c4c2981a842d3b6f5350d3
, but in any case the cursor control is only performed at fullscreen.

But I need to clarify: the commit (https://github.com/adventuregamestudio/ags/commit/6a35ec9936b545cbb4d405309f24359fbe6e80f5) makes your mouse lag for 20 seconds?


Crimson Wizard

#42
Quote from: morganw on Sat 05/03/2016 21:38:28
It is building for me, but unfortunately now I am seeing a problem with the mouse cursor. The cursor position is updating about 20 seconds after I move the mouse, so isn't usable to play a game.
There is something that I found: if I run the game with no scaling on large desktop, then it works very slow. It is not only mouse that moves slow, but everything: this is clearly visible if some animation is playing.

Yes, I can confirm that the "x11 lag" patch commit causes this.

As soon as I set any scaling filter, even x2 scaling, the slowdown stops.


Quote from: morganw on Sun 06/03/2016 09:38:41
But even with a controllable cursor (reverting the above commit), something seems to off with regard to fullscreen. The cursor movement is restricted to co-ordinates which are too small, contained to the top left corner of the game. Using x2 scaling increases the area it's possible to move in, and is a closer match to the actually game resolution, but still not correct.
I could not reproduce this, but when I run AGS games on my virtual machine, they always show up in the top-left corner, instead of the screen center. Since no one ever mentioned that, I was thinking this is because of how virtual machine works.

morganw

Quote from: Crimson Wizard on Sun 06/03/2016 14:24:37
But I need to clarify: the commit (https://github.com/adventuregamestudio/ags/commit/6a35ec9936b545cbb4d405309f24359fbe6e80f5) makes your mouse lag for 20 seconds?

Yes, in a window and fullscreen, the cursor only moves after a delay of around 20 seconds. There is no excessive CPU usage during this time.

Quote from: Crimson Wizard on Sun 06/03/2016 15:18:18
There is something that I found: if I run the game with no scaling on large desktop, then it works very slow. It is not only mouse that moves slow, but everything: this is clearly visible if some animation is playing.

Yes, I can confirm that the "x11 lag" patch commit causes this.

As soon as I set any scaling filter, even x2 scaling, the slowdown stops.

The problem I'm seeing is definitely based on restricted mouse position, not on load.

Quote from: Crimson Wizard on Sun 06/03/2016 15:18:18
I could not reproduce this, but when I run AGS games on my virtual machine, they always show up in the top-left corner, instead of the screen center. Since no one ever mentioned that, I was thinking this is because of how virtual machine works.

I think this goes some way to explaining the problem. The mouse restriction movement restrictions which are imposed seem to align with where the game would have been displayed if it was in the top left corner of the screen (instead of in the centre). Just to re-iterate, when I built 3.3.5 mid February I had no mouse issues at all, I noted unexpected load from applying standard scaling which slowed down everything, but without the excessive load the mouse behaved properly (in terms of position and control) in a window and fullscreen. This is why I asked if anyone else had seen the issues you were describing, perhaps the mouse issues you have seen are specific to how you run your VM.

Crimson Wizard

#44
Quote from: morganw on Sun 06/03/2016 16:32:02when I built 3.3.5 mid February I had no mouse issues at all, I noted unexpected load from applying standard scaling which slowed down everything, but without the excessive load the mouse behaved properly (in terms of position and control) in a window and fullscreen. This is why I asked if anyone else had seen the issues you were describing, perhaps the mouse issues you have seen are specific to how you run your VM.
Well, I was asking if anyone can confirm having or not having these issues on the latest version, but no one replied, so I did not know what to think.
The feedback I am getting is sporadic and often not clear enough to understand which version people test, and under which conditions.

morganw

I should be able to test it on another computer tomorrow afternoon, so I'll confirm if that acts the same way as the one I have at home.
What do you use to run your VM?

Crimson Wizard

Quote from: morganw on Sun 06/03/2016 16:50:22
What do you use to run your VM?
I am running Ubuntu installed under VMWare Player, if that is what you are asking about.

The thing is that I already disabled the mouse control on Linux several commits earlier.

morganw

I'll install VMware Player as well and see what it does. If it behaves the same way as you describe then I'll go back through the commits and test on the VM and an actual PC.

morganw

Okay, I've tried building with this VMware image.
During the setup I:
  • declined the installation of the host side keyboard driver
  • installed all VMware tool updates
  • installed all Ubuntu package updates
For me it acts the same way as the physical PC (very long delay on mouse input and cursor position is incorrectly restricted when fullscreen).

Leave it with me and I'll step through the changes.

morganw

It seems that the cursor movement restrictions begin to occur once the mouse control routines were disabled for Linux. I've tested with mouse control routines for Linux enabled and for me it all seems to be working fine (I can control mouse speed with the game config file without any sort of control or display issues). I would like to suggest reverting the X11 lag fix and enabling mouse control for the Linux platform. This would give the chance for any interested party to test for issues.

I think a lot of the issues you were seeing were actually down to bizarre behaviour of the VMware mouse or graphics integration. I've had it go completely haywire after a resolution change and at times it has been causing cursor alignment issues inside the VM (input is no longer aligned to the mouse cursor in the window manager - not even running the game). At one point I ran the same game I've always been testing, fullscreen, and it decided to display it aligned to the right edge of the screen instead of in the middle. I did also see the delayed mouse acceleration that you had described earlier but I can't recreate this outside of the VMware environment.

morganw

Quote from: blur on Sun 06/03/2016 02:14:38
I can confirm the mouse update problem for ags 3.3.5.3 on Linux in windowed mode with the game Mudlarks v1.6 but it works fine in full screen mode. The game Pendek works fine in windowed mode tough.
I think that you might not see the cursor movement restrictions if the game resolution is an exact fit for your display, i.e. you are running with no borders so there is no need to offset the game to centre it.

Monsieur OUXX

Thanks a lot to CW and the other contributors. Like, really. Really really!
 

Crimson Wizard

Quote from: morganw on Mon 07/03/2016 21:00:35
I think a lot of the issues you were seeing were actually down to bizarre behaviour of the VMware mouse or graphics integration. I've had it go completely haywire after a resolution change and at times it has been causing cursor alignment issues inside the VM (input is no longer aligned to the mouse cursor in the window manager - not even running the game). At one point I ran the same game I've always been testing, fullscreen, and it decided to display it aligned to the right edge of the screen instead of in the middle. I did also see the delayed mouse acceleration that you had described earlier but I can't recreate this outside of the VMware environment.

Thank you very much, that is very reassuring to me.
Enabling mouse control on Linux is indeed a simple thing; that is why I made an explicit switch in the Platform class.

Regarding the X11 lag patch, I added it after suggestion made by 2 Linux users, I know for certain that they were using this patch at least since 2014 (this is when one of them suggested it), and they claimed it actually helped them to improve mouse handling.
The way it starts glitching makes me think that there is something wrong in initialization; perhaps some control variables are not initialized properly. This needs to be investigated further before making final decision.


I am sorry, I got hugely stressed lately (because of these continiuos mouse bugs which I could not understand, + some other things outside of AGS). I think I will take a few days off development.

Crimson Wizard

#53
Released an update to 3.3.5 RC (now 3.3.5.4 RC3).

Installer: http://www.adventuregamestudio.co.uk/betas/AGS-3.3.5.exe
ZIP archive: http://www.adventuregamestudio.co.uk/betas/AGS-3.3.5.zip
No-MP3 engine: http://www.adventuregamestudio.co.uk/betas/AGS-3.3.5-noMP3.zip


This update fixes few remaining bugs we found lately.
If nothing else is found in following several days, I think this may be released as final 3.3.5 version.


Added changes:
Editor Bug Fixes:
- Fixed crash when importing sprite from clipboard (regression).

Engine Features:
- Added a config option which lets you to explicitly disable mouse speed control. This is rather an emergency switch, because so far the only problems with new mouse code were found on VMWare running Linux (probably a cause of imperfect emulation).

Linux:
- Fixed incredible slowdowns if no scaling filter is selected (this was due the improper patch used in previous version, which is now reverted).
- Enabled mouse speed option for Linux. The problem I found earlier appeared to affect only Linux run under VMWare.



SMF spam blocked by CleanTalk