AGS 4.0 - Early Alpha 10 for public test

[Crimson Wizard]

Yes of course, having dynamically created objects would be an important and useful functionality.
But there is a number of problems and design questions that have to be resolved first. Especially if we don't want to push another set of ugly hacks into the engine. I need to gather up the information about everything that has to be solved, and write a ticket about this.

At the moment the dynamic creation of objects is not even in the first ags4 milestone draft:
https://github.com/adventuregamestudio/ags/issues/1298

There's always something else that has to be worked on. Always more and more tasks, problems and requests stacking up, and for some reasons their numbers are not diminishing, but rising in time. From all the tasks that I've been scheduling for a period of time, I accomplish around 50%, or less, and am constantly changing plans due to urgent requests. It's going like this for years.

This project has always been lacking a proper project manager who would work on setting up priority tasks and keep team focus on them.
As well as more help, at least to deal with minor tasks.

[eri0o]

About dynamically created objects we need to first have either delegates (#1409) or pointer downcast (#2018), so we can pass a function/action object from script to a function/attribute that "links" the necessary interactions. Since any of these will probably be exclusive to the new compiler and ags4 is meant to have both the old and the new compiler for a while, we can't do it there until the old compiler is let go - assuming the new dynamic creation will be the only way. So I don't see this making into ags4 without big changes (possibly breaking).

About AGS dev, I honestly think a lot of the problem is lack of people, for development. See this example from scummvm, there is like 5 people doing tests and trying different code ideas to solve a problem (our old FreeType dependency due to breaking changes in font metrics). A PM would be nice, but they would have trouble scoping with the limited resources - one more senior ags dev would be ideal, as I think only CW is senior among the contributors. Unfortunately I don't know how to get more devs or make the project more approachable.

[vga256]

About dynamically created objects we need to first have either delegates (#1409) or pointer downcast (#2018), so we can pass a function/action object from script to a function/attribute that "links" the necessary interactions. Since any of these will probably be exclusive to the new compiler and ags4 is meant to have both the old and the new compiler for a while, we can't do it there until the old compiler is let go - assuming the new dynamic creation will be the only way. So I don't see this making into ags4 without big changes (possibly breaking).

Thanks for pointing out these challenges. As I'm not familiar with the compiler architecture, it helps to know this isn't a simple fix. From my perspective as a game developer, I can write "I wish AGS had..." type requests all day 

[abstauber]

Just a small observation while I've been tinkering around with this: AGS 3.6.1b7 is quite a bit faster.

My testgame draws almost everything directly on a room surface and is quite heavy on the scripting side. In AGS 3.6.1b7 I get around 517 FPS, whereas in AGS4a3 it's 'just' around 310 FPS. But apart from this and the 16-bit graphics issue, it appears to be pretty stable indeed.

[Crimson Wizard]

My testgame draws almost everything directly on a room surface and is quite heavy on the scripting side. In AGS 3.6.1b7 I get around 517 FPS, whereas in AGS4a3 it's 'just' around 310 FPS.

This is a serious difference, and is quite unexpected. Could you send us your test game for analysis?

Also, were you using old or new script compiler? We still support both, and old one is chosen in General Settings by default when you import old game, because the new one has stricter syntax rules. But new compiler is known to produce more efficient compiled script.

It's General Settings -> Compiler -> Use extended script compiler

[abstauber]

The extended compiler is not too happy with all my legacy stuff going on, especially the tween module seems to need an update.
Anyhow the game starts and the difference is now a bit lower.

AGS361


AGS4

[Crimson Wizard]

The extended compiler is not too happy with all my legacy stuff going on, especially the tween module seems to need an update.

I do recommend upgrading eventually, the new compiler provides much more useful syntax features, and possibly old one will be dropped at some point.

EDIT: Hm, actually, I notice that it compiles fine the project that you sent me. It prints warnings, some of them may be ignored (ones regarding default values), but others point to actual logical mistakes.

[abstauber]

Thanks a lot for looking into this. Updating the code of my "game" for AGS4 is actually a great idea - and it's a good opportunity to get familiar with it once again.

[Crimson Wizard]

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

This is AGS 4.0 Early Alpha 4.

Contains updates and fixes from 3.6.1 Beta 7 and 8.

Other changes:

Editor:
- Translation sources are now saved in PO format.
- Fixed room data xml was saved without linebreaks and indentation.
- Fixed all room images (backgrounds, masks) were rewritten on disk each time a room is saved, even if they are not modified.

Compiler:
- Fixed forward-declared but unresolved function not reported correctly.
- Fixed accessing dynamic arrays with a numeric literal index was not tested for "out of bounds" mistake.
- Fixed multidimensional array index delimiters (",") were confused with function parameter delimiters in call to a function.

Script API:
- Added Joystick struct, meant to work with joystics and gamepads in script.

Engine:
- Support joystick and gamepad input.
- Fixed DynamicSprite.CreateFromSaveGame producing invisible screenshot sprites.
- Fixed an attempt to read screenshot from a save with no screenshot could cause engine to crash.
- Fixed 16-bit sprites in 32-bit games turning completely transparent.


WARNINGS:

1. SpeechCenter plugin will stop working with this AGS 4 update. It won't crash, but won't see translated strings. This is because Translation storage had changed in the Editor. The plugin will have to be updated to work with AGS 4.

2. AGSJoy plugin will not compile with AGS 4, because its Joystick struct will conflict with the AGS own Joystick struct. The solution is to either disable newest script API level (by lowering to v3.6.1, but that will also disable anything else), or adjust the code to work with the new Joystick API. The API is relatively simple, so upgrading should not be a huge problem. The plugin is no longer needed after that.

[nightmarer]

Hello, I tried to open my project with this version and I got the following error.

https://imgur.com/vJpzMms
https://imgur.com/rJtGzU3

Error: El intervalo solicitado se extiende más allá del final de la matriz.
(This means: the interval requested is extended beyond the end of the array).
Version: AGS 3.99.107.0

System.ArgumentOutOfRangeException: El intervalo solicitado se extiende más allá del final de la matriz.
   en System.Runtime.InteropServices.Marshal.CopyToNative(Object source, Int32 startIndex, IntPtr destination, Int32 length)
   en AGS.Editor.BitmapExtensions.SetRawData(Bitmap bmp, Byte[] rawData, PixelFormat pixelFormat)
   en AGS.Editor.ObjectsEditorFilter.Paint(Graphics graphics, RoomEditorState state)
   en AGS.Editor.RoomSettingsEditor.bufferedPanel1_Paint(Object sender, PaintEventArgs e)
   en System.Windows.Forms.Control.OnPaint(PaintEventArgs e)
   en System.Windows.Forms.Control.PaintWithErrorHandling(PaintEventArgs e, Int16 layer)
   en System.Windows.Forms.Control.WmPaint(Message& m)
   en System.Windows.Forms.Control.WndProc(Message& m)
   en System.Windows.Forms.ScrollableControl.WndProc(Message& m)
   en System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   en System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   en System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

[Crimson Wizard]

Hello, I tried to open my project with this version and I got the following error.

Please tell, does this happen all the time, in any room, or in particular room?

[Crimson Wizard]

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

This is a small update, mostly to catch up with 3.6.1. Not many changes specific to AGS 4.

Contains updates and fixes from 3.6.1 Beta 9 to 12 (except ones related to backwards compatibility).

Other changes:

Common:
- Completely removed Global Messages and Room Messages.
- Removed built-in support for Game Score, including related game settings and GiveScore script command. Users are advised to script their own score counter if they need one.

Editor:
- Fixed "section" dropdown list in the script editor was getting broken by custom Color Themes.

Compiler:
- Accept constructor-like syntax (`T *o = new T();`), but skip the parentheses and do nothing, as AGS script does not really support constructors at this point. The purpose of this is to make it easier for users who have C++ or C# habits.
- Fixed "autoptr" struct's modifier required "builtin", should require only "managed".

Engine:
- Implemented more accurate Character movement. The movement direction is now more precise and diagonal movement speed no longer may exceed MovementSpeed setting.

[Crimson Wizard]

@vga256,

For the time being, GetAtScreenXY for Overlays alone would be hugely useful for projects like mine.

I've been thinking about potential issues for a while, and came to a realization that this would not be useful at all, at least not in the current circumstances.

Suppose the engine will find an Overlay under cursor and give it to you, how do you tell which overlay that is?
You see, other objects have IDs, they have ScriptName property, some have custom properties, or interactions which you may run.
But Overlays do not have IDs, or anything at all to report their meaning (at least not in a direct sense), or connection with anything. What would you do with this random Overlay?

The way I see this, searching for an overlay under cursor is almost pointless, as it's nothing but a sprite on a screen. That would have more sense to search in custom script data instead, which in turn "owns" Overlay as its visual representation. Then we'd probably need an opposite kind of test: not Overlay.GetAtScreenXY() that finds some overlay under the coordinates, but Overlay.HitTest() that tells whether a particular overlay is under coordinates. But then, it may be easier and faster to test for a bounding rectangle right in script, unless your overlay is shape-transformed (rotated etc) or you need a pixel perfect test.

I suppose this requires a good forethought to investigate the use case and potential usability issues.

Besides this, ther's a number of problems regarding performance and object validation when doing GetAtScreenXY(). I'll put them under the spoiler:

Spoiler

1. Performance
The engine does not have any "magic" to spot overlays under the cursor, so it has to do some kind of a search. The most primitive method is to iterate all existing overlays and test each one's bounding box. That could work as a simple formal solution.
But given Overlays are not limited anymore, the game may have many thousands of them, and then this search will become slow. So this will not work as a general solution.

This problem may be countered by introducing object groups, where each group is limited by certain portion of the screen, and maybe even by z-order range (so x,y,z position). This would mean that the engine should be ready to move overlay between these groups whenever overlay changes its position or size.
Note: if this system is created, then this has to be done regardless of whether game script has a call to Overlay.GetAtScreenXY() ever or not at all.
Then, @eri0o has a concern that any changes to overlays update will make overlays "less fast", and he's being using them in many thousands in his games, and put an effort to make this work as fast as possible. I don't know and cannot tell beforehand how impactful such "grouping" system could be to the existing performance. But it's definite that such system has to be well designed and performance tested first.
On another hand, popular engines seem to separate objects that support hit detection and those which do not. This lets reduce number of objects that may be searched for. This may be done through type hierarchy, or components. For instance, iirc, Unity 3D requires an object to have a "collider" component in order to be detected by a hit test. Possibly only those "colliders" are involved in a object search mechanics. Is this also a way to go with Overlays in AGS, by making a distinct interactable type derived from them? i cannot tell, and this problem is also complicated by AGS being generally "clunky" when it comes to type hierarchy in script (lack of proper pointer casting, and so forth).

2. Validation
Then there's something else: engine does not know how do you use Overlays, and what for. But you do.
This means that you may have better idea on how to separate wanted and unwanted overlays for your search.
Look at this example: you are using Overlays to generate dynamic GUI controls, so you store them in arrays and describe their relations using pointers. If you are doing a click test - then first you may find out which parent GUI is under cursor, and then search in its children. This may be faster than searching all existing overlays.
If you are using overlays to create a tilemap, then you may narrow search down to a certain visible portion, or group of tiles close to coordinates, if these tiles would store pointers to overlays on top of them, for instance.
Not only your own search may be more optimal than engine's but also it may be more valid. As engine will search for any overlays at all, including standard ones like character speech, while you may want to limit the search to overlays that serve particular purpose in your game.

[close]

[Exkodius]

Hi! I'm a long time lurker to these here forums and thought that i had to finally register to give a little heads up about a bug i found in trying out the early aplha 6 version.

In my project i work with 8-bit 256 colors. Sadly it seems that this version of the editor really does not like that, as it refuses to import my room backgrounds as anything other that 32-bit.

The new room subfolder structure is new to me so i might have missed something important. I did try to manually convert the image in the subfolder back into 256 colors and change the value of <ColorDepth>32</ColorDepth> to <ColorDepth>8</ColorDepth> in data.xml to no avail. I do get it to compile and run, but the colors are a garbled mess.

Any advice would be appriciated and a big thanks for still going strong after all these years!

[Crimson Wizard]

Hi! I'm a long time lurker to these here forums and thought that i had to finally register to give a little heads up about a bug i found in trying out the early aplha 6 version.

In my project i work with 8-bit 256 colors. Sadly it seems that this version of the editor really does not like that, as it refuses to import my room backgrounds as anything other that 32-bit.

Hello.
I guess nobody tested the new version with 8-bit games yet. I'll try this and open a bug ticket.

EDIT:
https://github.com/adventuregamestudio/ags/issues/2218

[Crimson Wizard]

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

Contains updates and fixes from 3.6.1 Beta 13 to 15 (except ones related to backwards compatibility).

Other changes:

Editor:
- Fixed occasional crash when scrolling the room in the editor.
- Fixed room not getting recompiled with a new content if a background or a mask was modified externally.

Scripting:
- Multi-dimensional dynamic arrays, also known as "jagged arrays". These are arrays of arrays, where each parent array's element has to be created separately, but may be of any independent length.
- Regular arrays of dynamic arrays: that is a regular array where each element is a pointer to a dynamic array of the same type.
- Dynamic arrays of regular structs.


This update contains a wonderful addition to scripting by @fernewelten : multidimensional dynamic arrays. Also known as "jagged arrays", because each sub-element may have its own length.

In these each element of all dimensions except last one is a pointer to another dynamic array, and elements of last dimension are values of the array's type. All sub-arrays must be created individually, but also may have a independent length.

First you must create the "parent" array, then you may create sub-arrays for each of its elements. Each nesting level the sub-array has one dimension less. When you create actual arrays, only the first dimension must have a fixed size, and following dimensions still have undefined size.

About like this:

Code: ags

// declare a 3-dimensional array
int dyn_arr[][][];
// create 3-dimensional array of size 10
dyn_arr = new int[10][][];
// for the 5th element of the first dimension,
// create a 2-dimensional array of size 20
dyn_arr[5] = new int[20][];
// for the 6th element of the first dimension,
// create a 2-dimensional array of size 25
dyn_arr[6] = new int[25][];
// for the 15th element of the 5th element,
// create a 1-dimensional array of size 40
dyn_arr[5][15] = new int[40];
// finally we may access the actual integer values
dyn_arr[5][15][35] = 100;

Regular arrays of dynamic arrays are also supported, and also may be of any number of dimensions. For instance, you could have this "mixed" array:

Code: ags

int overcomplicated_array[10][20][][];

Here first upper dimensions are fixed in script memory, and the two last ones are dynamic.

Code: ags

overcomplicated_array[5][15] = new int[100][];
overcomplicated_array[5][15][50] = new int[200];

[Rulaman]

After a short Test with the AGS4 alpha 7 version I found some problems.

The conversion (from AGS 3.6.12 beta 13) was ok, but the crm files did not get deleted. (I expected this)

And I could not display any rooms objects

Error: Der angeforderte Bereich geht über das Arrayende hinaus. <- Index out of bound
Version: AGS 4.00.00.02

System.ArgumentOutOfRangeException: Der angeforderte Bereich geht über das Arrayende hinaus.
 bei System.Runtime.InteropServices.Marshal.CopyToNative(Object source, Int32 startIndex, IntPtr destination, Int32 length)
 bei AGS.Editor.BitmapExtensions.SetRawData(Bitmap bmp, Byte[] rawData, PixelFormat pixelFormat)
 bei AGS.Editor.BitmapExtensions.SetRawData(Bitmap bmp, Byte[] rawData)
 bei AGS.Editor.ObjectsEditorFilter.Paint(Graphics graphics, RoomEditorState state)
 bei AGS.Editor.RoomSettingsEditor.bufferedPanel1_Paint(Object sender, PaintEventArgs e)
 bei System.Windows.Forms.Control.OnPaint(PaintEventArgs e)
 bei System.Windows.Forms.Control.PaintWithErrorHandling(PaintEventArgs e, Int16 layer)
 bei System.Windows.Forms.Control.WmPaint(Message& m)
 bei System.Windows.Forms.Control.WndProc(Message& m)
 bei System.Windows.Forms.ScrollableControl.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)

I debugged the error to the following function

public static void SetRawData(this Bitmap bmp, byte[] rawData, PixelFormat pixelFormat)
{
    BitmapData data = bmp.LockBits(new Rectangle(0, 0, bmp.Width, bmp.Height), ImageLockMode.WriteOnly, pixelFormat);
    int pixelCount = Math.Abs(data.Stride) * data.Height;
    Marshal.Copy(rawData, 0, data.Scan0, pixelCount);
    bmp.UnlockBits(data);
}

The bitmap size is 14x20
the pixelCount 1120
and the rawdata length is 560

I think there is some problem with the conversion.

When I get back in the callstack, i get the sprite info which is Format16bppRgb565
but this will be put over a Format32bppArgb image.

using (Bitmap sprite = Factory.NativeProxy.GetBitmapForSprite(obj.Image))
using (Bitmap sprite32bppAlpha = new Bitmap(sprite.Width, sprite.Height, PixelFormat.Format32bppArgb))
{
    sprite32bppAlpha.SetRawData(sprite.GetRawData());
    graphics.DrawImage(sprite32bppAlpha, xpos, ypos, spriteSize.Width, spriteSize.Height);
}

Code: ags

The code tags looks very ugly.

Rulaman

[Crimson Wizard]

The conversion (from AGS 3.6.12 beta 13) was ok, but the crm files did not get deleted. (I expected this)

The crm files are still used in a compiled game, but they are strictly output files now. They are updated when you do Build game and put inside game data. On another hand, when the game is run from editor in "Test run" mode, the game files are not packed and engine reads these files directly from disk. This makes game test launch faster. They are never deleted for the same reason: to make things faster if you re-run test game repeatedly.
This may be a good idea to move these into some "intermediate output" folder though, so to not confuse people.

And I could not display any rooms objects

<...>

I think there is some problem with the conversion.

When I get back in the callstack, i get the sprite info which is Format16bppRgb565
but this will be put over a Format32bppArgb image.

using (Bitmap sprite = Factory.NativeProxy.GetBitmapForSprite(obj.Image))
using (Bitmap sprite32bppAlpha = new Bitmap(sprite.Width, sprite.Height, PixelFormat.Format32bppArgb))
{
    sprite32bppAlpha.SetRawData(sprite.GetRawData());
    graphics.DrawImage(sprite32bppAlpha, xpos, ypos, spriteSize.Width, spriteSize.Height);
}

So your object sprite is 16-bit but it tries to interpret its pixel data as 32-bit? I will test this myself too and open a bug ticket.

Code: ags

The code tags looks very ugly.

If you have problems with these please mention this in "Site & Forum Reports", the forum and website is not something that AGS developers are responsible for:
https://www.adventuregamestudio.co.uk/forums/site-forum-reports/

[Kastchey]

Not sure if this is intended, but DialogOptionsRenderingInfo seems to have lost .HasAlphaChannel property in 4.0.

AGS 3.6:


AGS 4.0:

[Crimson Wizard]

Not sure if this is intended, but DialogOptionsRenderingInfo seems to have lost .HasAlphaChannel property in 4.0.

Yes, it's been cut out, as well as from DynamicSprite and DrawingSurface.
In AGS 4.0 we decided that all 32-bit sprites and surfaces assume valid alpha-channel, because having this property complicated the engine behavior.

This is mentioned in the changelog in the first post.

- Removed "hasAlphaChannel" param from DynamicSprite.Create() and CreateFromExistingSprite().
- Removed HasAlphaChannel property from DialogOptionsRenderingInfo.

EDIT:
I must clarify, the normal transparent color also works, both when importing a sprite, or when drawing with COLOR_TRANSPARENT in script, because it has alpha 0. In the future we plan to support full RGBA color definition in color properties and script drawing.