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

SMF spam blocked by CleanTalk