AGS 3.3.5 -- Release Candidate

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

Previous topic - Next topic

Crimson Wizard

This is a preliminary release of AGS 3.3.5. It is meant for public testing and gathering user opinions.

NOTE: This might be the last update to AGS 3.3 line; I am planning on bringing AGS 3.4 into beta stage next, and continue from that onwards.


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


Please, read before using
This update adds a serious change that may be, though, not noticeable at first (and many players will probably not notice it at most times).
The change was discussed at: http://www.adventuregamestudio.co.uk/forums/index.php?topic=52897.0

Since 3.3.5 AGS does not allow to write any files into other path rather than "$SAVEGAMEDIR$" (personal user saves directory) or "$APPDATADIR$" (all-users game data directory). An attempt to open file for writing at any other path from script will make engine automatically remap the path to $APPDATADIR$. If your game is built in Debug mode, it will also print a warning into "warnings.log".

At the same time the players are allowed to set up their own custom path to write game saves & data in. This basically works as remapping $SAVEGAMEDIR$ and $APPDATADIR$ to custom location. Game script will be "unaware" of this, and work as usual.

Conceptually, AGS is gradually leaning towards using only "symbols of file locations" rather than actual, explicit locations.

Furthermore, winsetup will now write config file into game saves location, rather than game's installation directory. If config file is present in the game installation folder, then it is used as "default" read-only config file. The config in saves folder overrides default one.
This way it should be totally safe to install any AGS game into C:/Program Files, without having administrative rights, or even have it installed on device with read-only access.


Changes since version 3.3.4:

Editor Features:
- Path to resource's (sprite, audio) source file is now saved as relative one if the file is
  located inside game project's folder.
- Removed arbitrary limit of the script imports (was 50000).
- Script allows struct member qualifiers to be in any order.
- Better detection of integer constants overflow in script.
- Removed arbitrary limit of integer default value of +/-32000. Integer values are now limited
  by correct 32-bit values (-2147483648 to 2147483647).
- Support for negative constants in enums.
- Better folding markers and indentation guides in script editor.

Editor Bug Fixes:
- Fixed compiler crash if unknown keyword used after "readonly".
- Fixed compiler did not properly report incorrect type of dynamic array in function declaration.
- Fixed compiler did not report proper type name in case of syntax error sometimes.
- Fixed mouse cursor flicker above the script editor.

Engine Features:
- Removed unconfigurable mouse cursor's acceleration.
- Support for mouse cursor speed control: may be defined in configuration and changed in script).
- A config option for keeping consistent cursor speed relative to user's desktop resolution.
- Support for locking mouse inside window: automatic lock is enabled in configuration, and user
  may use Ctrl+Alt combination to lock/release mouse at any time.
- Restricted writing game files to special system directories
  (game is forbidden to write files into installation directiory or by absolute path).
  For old games unsafe paths are remapped.
- Support for player defined saves & game file directory.
- -v/--version command line argument makes engine display its version and bail.

Engine Bug Fixes:
- Fixed crash if screenshot is taken while game window was minimized or moving.
- Fixed alpha blend did not work properly for speech portrait if blinking frame did not have alpha channel.
- Fixed Display and Say script commands were displaying text for minimal amount of time under certain conditions.
- Fixed legacy audio functions did not start digital music playback if MIDI driver failed to initialize.
- Fixed game was run in smallest possible window if graphics driver failed to initialize fullscreen mode.
- Fixed "--help" command line argument not working all times depending on its order.
- Fixed engine did not always properly closed application window when running debug build.

Script API:
- Supported late_repeatedly_execute_always() callback in script, called after game has updated, but
  before it is drawn.
- Added Mouse.ControlEnabled (readonly) and Mouse.Speed properties.
- Added System.HasInputFocus property which tells if game currently has focus or runs at background.

Cosmetics & convenience:
- Clarified disabled MIDI option name in WinSetup.
- Extended information displayed if graphics driver failed to initialize.
- Clarified error messages for running unsupported games.


Mehrdad

Great features CW. nice job. Please change limited 30000 sprites to unlimited. It's very useful for my project and it's so emergency.I have many animations into the game. Is it possible in this version?
My official site: http://www.pershaland.com/

Crimson Wizard

#2
Quote from: Mehrdad on Sun 22/11/2015 13:13:13
Great features CW. nice job. Please change limited 30000 sprites to unlimited. It's very useful for my project and it's so emergency.I have many animations into the game. Is it possible in this version?
No, I cannot do this now.

I could maybe increase this limit, but the sprite system is made so it will require redesign to make the sprite count truly unrestricted.

The thing is, also, that this version is taking too much time for some reason, and 3.4 takes unreasonably long time. I want to bring them to safe state and release them as soon as possible.

Mehrdad

Quote from: Crimson Wizard on Sun 22/11/2015 14:11:51
I could maybe increase this limit, but the sprite system is made so it will require redesign to make the sprite count truly unrestricted.

How many can you increase it? Double is enough (60000) . Is it possible?
My official site: http://www.pershaland.com/

Crimson Wizard

Quote from: Mehrdad on Sun 22/11/2015 17:52:46
How many can you increase it? Double is enough (60000) . Is it possible?
I will take a look into this when I'm done with some other task; probably in a week or so.

Monsieur OUXX

 

Crimson Wizard

#6
Released an update to 3.3.5 Beta (now 3.3.5.1).

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

Please, read before using
This update adds a serious change that may be, though, not noticeable at first (and many players will probably not notice it at most times).
The change was discussed at: http://www.adventuregamestudio.co.uk/forums/index.php?topic=52897.0

Since 3.3.5 AGS does not allow to write any files into other path rather than "$SAVEGAMEDIR$" (personal user saves directory) or "$APPDATADIR$" (all-users game data directory). An attempt to open file for writing at any other path from script will result in script error! [NOTE: games created by older versions of AGS won't produce error message, but will have their file paths remapped].

At the same time the players are allowed to set up their own custom path to write game saves & data in. This basically works as remapping $SAVEGAMEDIR$ and $APPDATADIR$ to custom location. Game script will be "unaware" of this, and work as usual.

Conceptually, AGS is gradually leaning towards using only "symbols of file locations" rather than actual, explicit locations.

Furthermore, winsetup will now write config file into game saves location, rather than game's installation directory.  If config file is present in the game installation folder, then it is used as "default" read-only config file. The config in saves folder overrides default one.
This way it should be totally safe to install AGS games into C:/Program Files, without having administrative rights.


Added changes:

Editor Bug Fixes:
- Fixed mouse cursor flicker above the script editor.

Engine Features:
- Restricted writing game files to special system directories
  (game is forbidden to write files into installation directiory or by absolute path).
  For old games unsafe paths are remapped.
- Support for player defined saves & game file directory.
- -v/--version command line argument makes engine display its version and bail.

Engine Bug Fixes:
- Fixed game was run in smallest possible window if graphics driver failed to initialize fullscreen mode.
- Fixed engine did not always properly closed application window when running debug build.

Script API:
- Supported late_repeatedly_execute_always() callback in script, called after game has updated, but
  before it is drawn.

Cosmetics & convenience:
- Clarified error messages for running unsupported games.


KNOWN ISSUES (expected to be fixed):
- Minimal negative integer literal (-2147483648) is not parsed properly.

TODO:
- Update the manual.
- Few minor fixes, mostly related to Linux port.

monkey0506

Gives an error when loading:

Quote---------------------------
Error
---------------------------
An unexpected error occurred trying to start up the AGS Editor. Please consult the details below and post the error to the AGS Technical Forum.

System.IO.FileLoadException: Could not load file or assembly 'AGS.Native, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail. (Exception from HRESULT: 0x800736B1)

File name: 'AGS.Native, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' ---> System.Runtime.InteropServices.COMException (0x800736B1): The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail. (Exception from HRESULT: 0x800736B1)

   at AGS.Editor.NativeProxy..ctor()

   at AGS.Editor.NativeProxy.get_Instance()

   at AGS.Editor.ApplicationController..ctor()

   at AGS.Editor.Program.startupTimer_Tick(Object sender, EventArgs e)

   at System.Windows.Forms.Timer.OnTick(EventArgs e)

   at System.Windows.Forms.Timer.TimerNativeWindow.WndProc(Message& m)

   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)




---------------------------
OK   
---------------------------

Then hangs on splash screen. Have to kill it from Task Manager. 3.3.4 runs fine on the same system.

monkey0506

3.3.5.1 loads fine on my home computer. Perhaps there is a mismatch in Native DLL version?

Crimson Wizard

Quote from: monkey0506 on Mon 25/01/2016 16:48:24
3.3.5.1 loads fine on my home computer. Perhaps there is a mismatch in Native DLL version?

I am usually testing Editor installation on a clean Windows XP virtual machine.
Such error is displayed if I don't choose to install corresponding Visual C++ Redistributable. If I install VC++ redist which comes with installer (9.0.30729.6161), then Editor loads fine.
Did you have such runtime libraries installed and if yes, then what kind of OS were you trying this on?

monkey0506

I can look later and see which VC++ runtime(s) are installed on that system, but is there a change in the required runtime from 3.3.4 to 3.3.5.1? Again, 3.3.4 runs on that system without problem.

Crimson Wizard

Quote from: monkey0506 on Wed 27/01/2016 18:46:40
I can look later and see which VC++ runtime(s) are installed on that system, but is there a change in the required runtime from 3.3.4 to 3.3.5.1? Again, 3.3.4 runs on that system without problem.
There should not be, but 3.3.5 is the first version built by automatic server. Supposedly it should use same libs for building...

AGD2

#12
When testing this, I receive a compile error if I try to call a function which has optional parameters, and don't supply any of said optional parameters. For example:

In the script header:

import static void DestroyByType( int type, int quantity = 1, float durability=-1, int targetenchant=-1);

In the game script:

ItemPool.DestroyByType( iVendorSelection );

Compile Error:

dynamicInventory.asc(1576): Error (line 1576): Not enough parameters in call to function

Gurok

#13
I blame Sonneveld! Just kidding. There was one instance where the new default parameter flag wasn't being propagated. I made a pull request to fix it.

https://github.com/adventuregamestudio/ags/pull/310

I understand why this change was made, but I think it might have been better in the 3.4.x branch.
[img]http://7d4iqnx.gif;rWRLUuw.gi

Crimson Wizard

Just heads up: the bugs we know were fixed, I am planning to make new build in 1-2 days, which may easily be a "release candidate" of 3.3.5.

Crimson Wizard

#15
Have anyone tried this under Linux? I am observing a very bad issues with new mouse control in fullscreen; it looks like mouse cursor lags behind terribly.

EDIT: there is something wrong going on when Allegro tries to reposition mouse cursor under Linux. It works flawlessly under Windows, but under Linux it causes something like mouse lag: it's like mouse driver duplicates commands and continues to move mouse to same direction for some time even after you started moving it to another.

It was always like that, I tried older AGS builds, and it happens whenever engine repositions mouse cursor that went beyond the game's bounding box.

Looks like you cannot do that on Linux, or should do it somehow else.

morganw

#16
I've just built it and it acts in a similar way to when I built 3.3.4 and 3.4.x about 6 months ago. I can (sometimes) produce the type of mouse behaviour you describe, but only when running a game using a graphics filter, which causes XOrg to use excessive CPU time. Audio playback stutters at the same time. Removing the graphics filter (or using a faster computer) gives me normal mouse motion and the audio doesn't stutter.

Edit: Strangely I'm finding that the stdScale2 is causing much more of a problem then Hq2x, even though CPU usage looks even worse with the high quality scaling.

Crimson Wizard

#17
This is not the proper research, but I've found this: Allegro calls XWarpPointer to move the mouse cursor on Linux (this function is a part of XWindows), and according to the manual:
Quote
If you do use this function, however, it generates events just as if the user had instantaneously moved the pointer from one position to another.
I wonder if this causes these generated events to "loop back" to Allegro and AGS, producing duplicated movement...


E: I will try to rewrite AGS mouse logic without in a way that does not ever sets system cursor position, but only gets one.

morganw

I think same problem is described here:
https://www.allegro.cc/forums/thread/599171/6

A patch is in one of the posts and seems to directly relate to whether the cursor is inside or outside the window.

Code: c
Index: src/x/xmousenu.c
===================================================================
--- src/x/xmousenu.c	(revision 11745)
+++ src/x/xmousenu.c	(working copy)
@@ -192,21 +192,18 @@
 
    ALLEGRO_SYSTEM_XGLX *system = (void *)al_system_driver();
    Display *display = system->x11display;
+   ALLEGRO_DISPLAY_XGLX *d = (void *)al_get_current_display();
 
    int window_width = al_get_display_width();
    int window_height = al_get_display_height();
    if (x < 0 || y < 0 || x >= window_width || y >= window_height)
       return false;
 
-   int new_x = x;
-   int new_y = y;
-   int dx = new_x - the_mouse.state.x;
-   int dy = new_y - the_mouse.state.y;
+   _al_mutex_lock(&system->lock);
+   XWarpPointer(display, None, d->window, 0, 0, 0, 0, x, y);
+   _al_mutex_unlock(&system->lock);
+   
 
-   if (dx != 0 || dy != 0) {
-      XWarpPointer(display, None, None, 0, 0, 0, 0, dx, dy);
-   }
-
    return true;
 }

Crimson Wizard

#19
This issue is complicated, and I cannot know the origin of this problem without proper research.

Even though I removed calls to position_mouse, the lag was still present. It only went away when I replaced call to get_mouse_mickeys by manual calculation (remember old system cursor pos, and subtract from new one).
I think this means that Allegro does not process mouse events properly for some reason.

The lag is 100% reproducable and very clear visible on my system. I am runnin linux on virtual machine, so that may be a reason (it works slower).

morganw

Are you sure that it's not caused by a mouse acceleration feature of whatever you are using to run the VM? I've played 4 or 5 games on the Linux engine over the last year and it's never been an issue (the way you are describing it is as if the whole thing is fundamentally unusable). Also, have you got more than one CPU core available to the VM?

Crimson Wizard

#21
Quote from: morganw on Sat 13/02/2016 23:24:18
Are you sure that it's not caused by a mouse acceleration feature of whatever you are using to run the VM? I've played 4 or 5 games on the Linux engine over the last year and it's never been an issue (the way you are describing it is as if the whole thing is fundamentally unusable). Also, have you got more than one CPU core available to the VM?

The new mouse routine was added to the WIP branch only recently. This ONLY happens in fullscreen mode.

I do not think this is related to acceleration, its more like mouse movements are lagging behind. I move mouse to the left, then stop and then start moving it to the right, but cursor continues to move to left for some time. It looks like the event queue gets cloggered with extra "relative move" events.

E: or it can be that Allegro summs up extra dx/dy values at some point...



E2: The most interesting thing is that simply calling get_mouse_mickeys function without actually using returned values produce this effect...

E3: The real trouble is that I MUST use mouse_mickeys, because otherwise it is possible to get into situation when system cursor reaches the screen border, while the game cursor haven't, and player won't be able to move cursor any further. (This may happen e.g. if the cursor speed is lowered).

I need to find out what is going on...


Can someone else test this on Linux? I need to know if this happens only for me, or others can reproduce this too.

Mehrdad

#22
Is it possible add 640X360 support resolution in this version?
I think 3.4 takes long time for stable release.
As I need to this size for HD output.
My official site: http://www.pershaland.com/

Crimson Wizard

Quote from: Mehrdad on Sun 14/02/2016 16:18:21
Is it possible add 640X360 support resolution in this version?
No, I am done adding features to this version. I just have 1 issue to fix and the version is finished.

Crimson Wizard

#24
Released an update to 3.3.5 Beta (now 3.3.5.2 RC1).

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 is a mainly a bug-fixing update.


Added changes:

Editor Bug Fixes:
- Fixed parsing functions with optional parameters (regression);
- Fixed minimal negative integer literal (-2147483648) was not parsed properly (incomplete feature).

Manual:
- Updated to 3.3.5.


KNOWN ISSUES (expected to be fixed):
- Mouse cursor movement does not work well under Linux when running in fullscreen. This is pretty bad, and this version cannot be finalized without addressing this issue first.
- The Windows Installer uses application GUID from AGS 3.3.4, which will replace existin 3.3.4 installation with 3.3.5 in the installed program list, if you have installed 3.3.4 to your computer earlier. This is a small technical mistake, that will be corrected in final release.

AGD2

I gave this a quick test and the previous compile errors I reported are solved now. Hooray!

Though, I ran into a new one. Our game has some custom debug functions and one of them uses the .File functions to store and retrieve data from a .log file.

Code: ags

static void Debugger::ShowDebugMessage(String message, int iCategory, int iSeverity ){
#ifdef DEBUG
  if( gbShowDebugMessages ){
    File *logFile = File.Open("debug.log",eFileAppend);
    
    message = String.Format("%s|%d|%d", message, iCategory, iSeverity );
    
    logFile.WriteRawLine(message);
    logFile.Close();
    int i = GetNextFreeMessage();
    if (i < 0) return;
    DebugMessages[i].Message = message;
    DebugMessages[i].timer = 120;
  }
#endif
}


This function was called from game_start and it crashes with a "Null pointer referenced" error on the logFile.WriteRawLine and logFile.Close(); lines. (It also crashes if I move the function call from game start to a room's Load_room or After Fadein script. These lines/functions didn't cause a crash in previous editor builds.

A couple of other things:

1) In winsetup.exe, "Auto Lock to Window" works on my system, but the Mouse Speed slider doesn't seem to make any difference to the cursor speed in game (Win 7). When I quit and reload winsetup.exe, the slider always resets back to the default (x 1.0) position. However, if I load winsetup.exe, change the slider position, click Save, close winsetup without running the game, and then open winsetup.exe again, the slider will be saved at the last position I had set it to.

2) I downloaded the zip archive, and pressing F1 in the editor says that ags-help.chm is missing.

Crimson Wizard

#26
Quote from: AGD2 on Wed 17/02/2016 14:26:21
Though, I ran into a new one. Our game has some custom debug functions and one of them uses the .File functions to store and retrieve data from a .log file.
Please, read the information just below the red font line in the first post of this thread. It has an information regarding new file path rules.

E: the fact that it does not report error, but just returns a null pointer seem to be a bug...


Crimson Wizard

Quote from: AGD2 on Wed 17/02/2016 14:26:21
the Mouse Speed slider doesn't seem to make any difference to the cursor speed in game (Win 7).

Do you test in fullscreen or windowed mode?

AGD2

QuotePlease, read the information just below the red font line in the first post of this thread. It has an information regarding new file path rules.

E: the fact that it does not report error, but just returns a null pointer seem to be a bug...

Hmm, when I put $SAVEGAMEDIR$/ into the path it did start compiling fine again. Just figured I should report it anyway.

QuoteDo you test in fullscreen or windowed mode?

I had tested it in windowed mode. But just tested it in full-screen mode and that worked perfectly. :)

Crimson Wizard

#29
Quote from: AGD2 on Wed 17/02/2016 15:01:40
Hmm, when I put $SAVEGAMEDIR$/ into the path it did start compiling fine again. Just figured I should report it anyway.
I should note that you may find it easier to set up a custom path for writeable game files in winsetup (by default it should choose current directory) when testing the game, to have faster access to logs.

I was also considering to allow the game write to any random location if it is compiled with DEBUG setting, but I am not sure about that: it is easy to forget about this peculiarity and leave non-working code in game if you do not safeguard the script with "#ifdef DEBUG".

Quote from: AGD2 on Wed 17/02/2016 15:01:40
QuoteDo you test in fullscreen or windowed mode?
I had tested it in windowed mode. But just tested it in full-screen mode and that worked perfectly. :)
Ok, then it works as intended. I disabled the ability to control mouse cursor speed in windowed mode; that is technically possible, but I had doubts it may be usable.

Crimson Wizard

#30
I cannot stop thinking that I made a mistake putting this filesystem changes into minor update. With minor update users will expect they may continue working on their existing projects without fixing anything.
But it is too late now. I guess I should add a switch that would reset the behavior.


E: No, on second thought the switch idea seem wrong; I'd rather make it remap unsafe path to safe one with a warning to debug log (aka "warnings.log"), same as we do for old games now.
In other words, there won't be any script error, but the written file will end up in a "safe-to-write-into" directory.
Remember that you (and the player) can always setup their own location for saving game files into, including game location.

Crimson Wizard

Released an update to 3.3.5 RC (now 3.3.5.2 RC2).

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 is a mainly a bug-fixing update.


Added changes:
Engine Features:
- Changed the file paths behavior: now if you use the path relative to the game installation directory for writing a file, the path will be remapped to $APPDATADIR$, and a warning printed to warning.log (Debug game build only).
Earlier remapping was done only for games created with previous versions of AGS, and new games caused File.Open return null.

Engine Bug Fixes:
- Fixed engine was saving default mouse speed values to config when game run in windowed mode, overwriting user's settings.

Linux:
- Temporarily disabled mouse speed option for Linux. There seem to be something wrong in Allegro4 lib that does not let us use current cursor speed implementation. When we find out how to fix that, the option will be made working on Linux again. As of now, it simply cause no effect.
- Added patch that supposedly fixes mouse lag for mouses with high polling rate.

Manual:
- Updates in topics related to File functions.

Mehrdad

Thanks a lot CW for another great release. I switched and converted my game to this version today . It works fine. I don't see any problem at the moment ;) 
My official site: http://www.pershaland.com/

Crimson Wizard

#33
Too bad it was taking much more time than expected.

cianty

Awesome! Thanks a lot for all the hard work!
ca. 70% completed

Crimson Wizard

Can someone please tell if you are able to build AGS under Linux in "develop-3.3.5" branch?
We have makefile changed some time ago and now it does not work for me, unless I change it a little.
Since this is something beyond my current knowledge, I need to know if it's only my problem, or other people have it as well.

morganw

#36
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. Did you find anyone else to confirm the mouse cursor issue you described earlier in this thread? To me the older 3.3.5 build wasn't behaving any differently to how I remembered 3.3.4 or 3.4.0 builds.

Crimson Wizard

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. Did you find anyone else to confirm the mouse cursor issue you described earlier in this thread? To me the older 3.3.5 build wasn't behaving any differently to how I remembered 3.3.4 or 3.4.0 builds.
Does it behave so if you build the latest state of the branch? I explicitly disabled new mouse code for Linux for this time.

blur

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.

Crimson Wizard

That sounds different from what I experienced.
Would anyone be able to walk the history back and see if it was introduced recently?

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