AGS 4.0 - Alpha 18 for public test

[ThreeOhFour]

Out of curiosity, what features are you looking for feedback on? I'm using AGS 4 daily now, and am using some of the new features - but definitely not all of them. Overlay rotation and the add blend mode work perfectly. I haven't spent much time trying to rotate anything else, nor using the other blend modes, but can spend some time with them and give feedback if it's desired?

[Crimson Wizard]

Out of curiosity, what features are you looking for feedback on?

Any from the list, really. Even if only just the fact that they are being used, work as expected, and if are useful or not.
It's not clear at this point which were tried by other people than the devs themselves, since there had been little mention of this.

Then, there are those that are rather straightforward, and those that are complex. The latter may be of more interest.

1. New scripting features available with the new compiler; more importantly those that require using pointers: managed structs within managed structs, connecting custom managed objects together, and such. These involve both script compiler and the engine managing "garbage collection".
2. "Watch variables" panel.
3. From new scripting commands, it would be nice to see someone trying VideoPlayer, but I understand that's rather niche thing to have in games. That will mostly be useful if someone makes one of those "FMV style" games.
4. New Joystick/gamepad interface in script. It should replace a use of joystick plugin. But this is interesting for people who make gamepad controls in their games.
5. Translations, because they are now saved in a PO format. Although the usage should still be pretty straightforward, but I am curious if they cause any kind of trouble.

Earlier I would have also mention "Room editing" because of the new rooms storage format, but you can't miss it when you edit the game, so, I suppose. this was tested more than other things.

[eri0o]

Another feature that would be nice to get more experimentation is the PathFinder and MaskPathFinder API along with the path movement stuff - you can pass an array of Points to things to create a path that they should move along, at least for objects and characters. I think at the time only I and CW played with it.

[Snarky]

2. Documentation must be updated, and before that we need to have a proper support for 2 branches of the manual (3.* and 4.* at least).

I assume "proper support for 2 branches," means that it's not just a matter of forking the manual's Github repo, then.

[Crimson Wizard]

I assume "proper support for 2 branches," means that it's not just a matter of forking the manual's Github repo, then.

I don't know, maybe having 2 repositories is also a way, if branches don't work.

With 2 repos the wiki pages may be still being used to edit the manual (github does not support editing multiple branches through the "wiki" front).

This approach will become inconvenient if we want to have separate branch per maintained version, including minor versions. But it also may be a temporary "dirty" solution until something better comes up.

[Crimson Wizard]

Updated to Alpha 15
(Please use download links in the first post)

Contains all the new features from 3.6.2 Betas 3.

Own changes:

Editor:
 - The "Watch Variables" panel has an option to automatically enlist local variables (relative to current position in script) when testing the game.
 - Added "Add to Watch Panel" command to Script Editor's context menu.
 - Support dragging a text from the script window into the "Watch Variables" panel.
 - Fixed mistakes occuring when overwriting existing room files by a imported room.

Scripting:
 - Managed structs may have constructors. Constructor is a member function which name is identical to the struct's name, and type is "void". Constructor will be called automatically when the managed object is created with "new" command.
 - Dialog Scripts dropped support for a number of obsolete commands: "run-script", "new-room", "set-speech-view", "set-globalint", "play-sound", "add-inv", "lose-inv". All of those have contemporary equivalents.


Using constructors is more or less how you do it in C++/C#, except it has to be declared having a type "void", as opposed to no type at all (this is kept so for simplicity of compiler's work, idk if it's critical, but maybe we could look into letting to declare it completely typeless later).

Example:

Code: ags

// header
managed struct MyStruct
{
     import void MyStruct(int data); // this is constructor
     import readonly attribute int Data;

     writeprotected int _data;
};

// script
void MyStruct::MyStruct(int data)
{
     _data = data;
}

int get_Data(this MyStruct*)
{
     return _data;
}

// elsewhere in another script
function game_start()
{
     MyStruct *s = new MyStruct(10); // this actually calls constructor
     Display("%d", s.Data); // should display 10
}

[Crimson Wizard]

@yarooze , I moved the text boxes discussion here:
https://www.adventuregamestudio.co.uk/forums/beginners-technical-questions/re-ags-4-0-alpha-15-for-public-test/

[ThreeOhFour]

I've been taking a look at the alternate blending modes added to AGS 4.0 and some of them seem to handle alpha channels in a way different than I expect from these modes. Normal, additive and subtractive blending modes act exactly as I expect them to, but the rest seem to have trouble processing the alpha channel correctly, with alpha seeming to be processed without any gradation, and even blending where the image is completely transparent. Here's an example:

Normal blending mode

Mutliply blending mode

I'm using build 4.00.00.09, and I've put up a copy of the sprite used in this test here.

[eri0o]

I noticed it went unmentioned in last release notes here on the forums but there's an additional fix for the watch pane that could make the engine unresponsive if one "step into" too fast -  this made it hard to use the watch pane, but the latest 4.0.0.11 also fixed this, so now debugging is much smoother.

About the blending modes, the way they are currently implemented relies on DirectX and OpenGL own implementations, and I guess it may require some of those premultiply alpha settings.

They would be less driver dependent if we used shaders, but there is a detail here that the current use of shaders in the engine, for tint (color and lighting) and transparency, only depends on the data in the texture of the sprite itself. With blending modes the shader has to depend on the information "below", but currently, in the gfx drivers the previous drawn sprites aren't "rasterized" (or "flattened"), so it's not clear how one would get the information of the pixels below, I guess once it has to draw a sprite that has a blending effect it would need to "flatten" so that we can pass each pixel info to the shader drawing this sprite. Beyond investigating implementation there would be a need to check performance impacts, if any.

[Crimson Wizard]

To put it simply, not all of the blend modes were implemented correctly in all graphic renderers, and this has to be looked into before the final AGS 4 release.

BTW, there's a ticket that I wrote, about "reimplementing blend modes as shaders", but I wrote it just to have a formal reminder. It is quite possible that this cannot be done with shaders alone, since, as eri0o mentioned, for blending you have to combine pixels from current texture and pixels from already drawn textures below, and shaders cannot do that on their own afaik.

[ThreeOhFour]

Thanks for the information! I did some tests with the different drivers and see that there's a difference there. Good to know, thank you.

[yarooze]

The new features of AGS4 are great! Nested objects, multi dimensional arrays, watch variables window, shiny new editor windows.. I don't know, how we lived without them. 

Unfortunately, after I wrote some functions, the editor starts crashing from time to time without any warnings.

I click F5 or "run" button.
AGS popup "Please wait while your scripts are compiled..." appears.
Then the editor crashes and Windows popup "AGS Editor for Windows does't work anymore" appears.

This one:



The game can be compiled then, if I edit any script (adding some spaces or new lines is enough), save it and compile it again. So it seems, that I can reproduce this error and compile it correctly with the same code. 

I have some nested Object in my code (even some recursions), but it crushes on compile - not in the run time.

So my questions:
1. Is there any possibility to write some logs to find the problem?
2. Do anybody have such problem with the crushing editor?


I'm using Win10.

Code: ags

AGS Editor .NET 32-bit (Build 4.00.00.11) ** BETA VERSION **
v4.0.0, November 2024

[Snarky]

I seem to recall that people have experienced similar problems (not just with AGS4) caused by their antivirus, which for some unknown reason hates AGS. You could try disabling it temporarily and see if you can build.

[eri0o]

Just add an exception to your own game folder to Windows Defender and it should work I think. Maybe an exception to AGS Editor too, but I don't think that is needed.

I know the JetBrains IDEs I use for c++, python and Android all require to have the work directories added to Windows Defender otherwise I get some weird behavior.

[yarooze]

Windows Defender is actually deactivated. Trend Micro is active but has nothing in log.

[Crimson Wizard]

So my questions:
1. Is there any possibility to write some logs to find the problem?
2. Do anybody have such problem with the crushing editor?

There's no logging in the editor, other than compiler's errors.

You could PM us your project for a test, if this is a bug in the editor then we'll be able to see what is happening.

[Crimson Wizard]

@yarooze I checked your project, and it has a mistake in script that is known to cause all kinds of weird issues.

This is when you have "import" keyword used in function's body, like:

Code: ags

import void HemisphereElement::HemisphereElement(int id,  Hemisphere *hemisphere)
{

}

We have this crash already fixed and the fix will be included in the next update (coming soon).
Instead compiler will report a syntax error.
But you have to fix the script anyway.

[yarooze]

This is when you have "import" keyword used in function's body, like:

Oh.. looks like "silly me".

You mean: "Import belongs to the header. Export belongs to the code. Copypasta is evil."?

[Crimson Wizard]

Updated to Alpha 16
(Please use download links in the first post)

Contains all the new features and fixes from 3.6.2 Beta 4 (excepts ones related to backwards compatibility).


Own changes:

Editor:
- Added Flip property to View Frame, replacing a boolean Flipped property. The new property supports all 3 flip variants: horizontal, vertical and both at once.
- Fixed certain errors like "not terminated string" in Dialog Scripts did not report correct Dialog and line, making it difficult to find the cause of mistake.

Compiler:
- Fixed function bodies mistakenly declared with "import" keyword could cause program memory corruption during compilation.

Scripting:
- When calling a function you may specify parameter names like "name1: value, name2: value", and when doing so - pass arguments in any order.

Script API:
- Added Overlay.Flip property that lets to set one of the 3 standard flip styles.
- ViewFrame.Flipped property now returns eFlipDirection instead of bool.

Engine:
- Engine now supports up to 1024 simultaneously loaded scripts (was 128).
- Fixed Type.GetByName() not working (regression since one of the previous v4.0 Alphas).
- Fixed Software renderer not handling all the Overlay transformations correctly (like rotation).


In regards to naming parameters in the function call.

When calling a function, you can pass parameters having their names explicitly specified. This may be advantageous for the clarity of code. But in the end this is a user's choice of code style.

For example:

Code: ags

import int Func(int param, float fparam, String str_param);

void CallAnother()
{
    int result = Func(param: 10, fparam: 5.7, str_param: "text");
}

There are following rules:

* A function call must have either all passed parameters named, or none named. These two syntax styles cannot be mixed in the same function call.
* If you pass parameters named, they may go in any order.
* But, in any case, non-optional parameters (ones without default value) must be passed in the function call regardless of the syntax style used.
* If you are calling a variadic function (such as String.Format), and pass fixed parameters named, then you won't be able to pass variable parameters at all (because they don't have names!).

[yarooze]

I've got some strange behavior with the new AGS4 build a couple of time.

As I wrote the function (actually I did some copy pasta and change some parameters), I've got an error message:

Code: ags

Error: Der Index war außerhalb des Arraybereichs.
Version: AGS 4.00.00.12

System.IndexOutOfRangeException: Der Index war außerhalb des Arraybereichs.
  bei AGS.Editor.AutoComplete.GetFunctionParametersAsVariableList(ScriptFunction func, List`1 variables)
  bei AGS.Editor.AutoComplete.GetLocalVariableDeclarations(ScriptFunction func, List`1 localStructs, String scriptToParse, Int32 relativeCharacterIndex)
  bei AGS.Editor.ScintillaWrapper.CheckFunctionForLocalVariables(Int32 currentPos, ScriptFunction func, String scriptExtract, Boolean searchWholeFunction)
  bei AGS.Editor.ScintillaWrapper.GetListOfLocalVariablesForCurrentPosition(Boolean searchWholeFunction, Int32 currentPos)
  bei AGS.Editor.ScintillaWrapper.FindLocalVariableWithName(Int32 startAtPos, String nameToFind)
  bei AGS.Editor.ScintillaWrapper.GetFinalPartOfExpression(Int32 currentPos, ScriptStruct& memberOfStruct, Boolean functionsOnly)
  bei AGS.Editor.ScintillaWrapper.CheckForAndShowEnumAutocomplete(Int32 checkAtPos)
  bei AGS.Editor.ScintillaWrapper.ShowAutoCompleteIfAppropriate(Int32 minimumLength)
  bei AGS.Editor.ScintillaWrapper.OnUpdateUI(Object sender, EventArgs e)
  bei ScintillaNET.Scintilla.OnUpdateUI(UpdateUIEventArgs e)
  bei ScintillaNET.Scintilla.WmReflectNotify(Message& m)
  bei ScintillaNET.Scintilla.WndProc(Message& m)
  bei System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
  bei System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
  bei System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

"Der Index war außerhalb des Arraybereichs." means "The index is out of the array boundaries"

The Editor did not crash. Simple displayed me this message a couple of time. I was able to work further.

I'm not really sure how to reproduce it. I added parameters into the existing constructor (it had no parameter and was imported into the struct in the ash file). So I wrote something like this in the asc file:

Code: ags

void SkyViewElement::SkyViewElement(SkyView *skyView, int is = 0) 

ash was like this:

Code: ags

import void SkyViewElement();

Message as screenshot: