AGS 4.0 - Early Alpha 6 for public test

[Crimson Wizard]

AGS 4 - Early Alpha 4

Full release number: 4.0.0.1

ACHTUNG!

This is a EARLY ALPHA version of AGS 4. This is a WIP version, and must go through extensive testing. Use at your own risk. Please back up any games before opening them in this version of AGS. New settings in this version WILL make your project files unusable in previous versions after saving with this version.

Download AGS 4.0 Early Alpha installer

Download AGS 4.0 Early Alpha as a .zip archive

For Engine/Editor developers

Spoiler

AGS 4 source branch

Debug symbols database (for analysing crash dumps)

[close]

Last updated: 3rd November 2023

This release is brought to you by:

- Alan v.Drake
- Crimson Wizard
- eri0o (joystick & gamepad support, other improvements)
- fernewelten (new script compiler)
- ChamberOfFear, aka persn (open room format, Editor improvements)
-  Matteo Piovanelli (some improvements)



What is AGS 4

AGS 4.0 is an upcoming version which is currently in experimental stage. The primary idea of this version is a complete removal of the deprecated functionality: game settings and script functions. AGS 4 will no longer be able to run older 2.* or 3.* games. It will only guarantee the import of the latest 3.* game projects (such as 3.6.0). This means that if you want to update your existing game to AGS 4, then you'll have to first import and save it in 3.6.0. If your game is using any of the deprecated settings or script commands - you'll have to replace these, as 4.0 will no longer have necessary "backwards compatibility" switches in General Settings.

It is still in works, and there is a number of large changes planned.
But what are the ready major new features of AGS 4?

Open Room format

The new room format made by @ChamberOfFear now stores rooms as a collection of directories with room data split into multiple files. The room properties are stored in XML, which make it possible to read and even edit by hand outside of the editor. Room backgrounds and region masks are stored as separate PNG images.

This improves the safety of working with rooms, allows to change things externally, and simplify teamwork to some degree.

New script compiler with new syntax features

The new compiler was written by @fernewelten, and it grants a whole bunch of syntax improvements to the AGS script, such as nested structs, multi-dimensional arrays, dynamic arrays have `Length` pseudo-property, and so on.

The full cheat-sheet of the new features may be found here:
https://github.com/adventuregamestudio/ags/wiki/New-compiler%27s-end-user-cheat-sheet
If anyone is curious, here's the more "technical" version, explaining things in depth:
https://github.com/adventuregamestudio/ags/wiki/Features-of-the-new-Script-Compiler

Managed pointers inside managed structs

These are also allowed now (this is not related directly to the script compiler, but also to how engine handles dynamically created objects). This feature finally opens full potential of structs referencing each other with pointers, and allow you to create virtually any kind of data storage in script.

To give an example:

Code: ags

managed struct Item; // pre-declaration

managed struct Person {
    Item* items[];
};

managed struct Item {
    Person* owner;
};

Here's a LinkedList module I wrote for a test:
https://www.dropbox.com/s/sxur2bsccsvaqmr/ags399-LinkedList.zip?dl=0

Advanced object features

The game objects have two new features worth mentioning up front: Blend Mode and Rotation.
* BlendMode property lets you change the way object is drawn, selecting one of the 10 classic modes (Add, Subtract, Dodge, etc). This gives you ability to make more visual effects in your game.
* Rotation property (called GraphicRotation in some) lets you to rotate the object by a number of degrees. Most standard things have this, and even Cameras, so you may, for example, rotate the whole room view, and characters in it individually. Rotation is hardware accelerated (in Direct3D/OpenGL mode) and does not slow things down, unlike rotating dynamic sprites. Engine correctly detects clicks on rotated objects, so for example, rotated GUI will be fully functional.

What else is PLANNED for AGS 4?

Here's the milestone proposal:
https://github.com/adventuregamestudio/ags/issues/1298

It's not clear at the moment whether all of these features will be a part of the first 4.0 release, but at least some of these will hopefully be.

How safe is this WIP version currently?

It is relatively stable, and there are few people who were already using it to make games for a while: Alan Drake is one of them, and I suspect that fernewelten was also using it sometimes for his games because of his new compiler (but I may be mistaken).
The biggest problem with this is that this version will be updated further, so some things may not be final. Project format may also change in the next updates. We'll try to keep things upgradeable (so that the previous projects made in this WIP version won't just break).
And it surely it will benefit from more testers.


The full changelog follows:

Contains all additions from AGS 3.6.1 Beta 8, except ones made for backwards compatibility.

Common:
- Most of the deprecated functionality (game settings and script API) is cut out from both Editor and Engine, and is no longer supported. The Editor guarantees to import the projects saved by AGS 3.6.0 and later. The Engine may run games compiled in 3.6.0, but only so long as they don't use any deprecated settings or script commands.
- 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.
- Removed support for '[' as a linebreak character in text.
- Added FLAC support for music, speech and sound effects.

Editor:
- Open room project format: rooms are now saved as subfolders in "Rooms" folder, where each component has its own separate file (room data, backgrounds, masks and scripts).
- Support room backgrounds and masks as PNGs.
- Translation sources are now saved in PO format.
- General panel look enhancements.
- Support built-in Base Color Themes that have the custom themes applied over them.
- Game template selection now displays template's description right in the dialog.
- F2 is now a hotkey for editing labels in the Project Tree. "Game statistics" are now displayed by Ctrl + F2.
- Script editor supports "word wrap" mode.
- In General Settings added "Use extended compiler" option that lets to choose a new script compiler for your game (see list of changes in related section below).
- Added BlendMode property to Characters, GUI and Room Objects.
- Added readonly Length property to AudioClips, for the reference.
- Fixed faulty double-click on project items in case user dragged the cursor away.

Compiler:
- The new extended script compiler is available. Almost all of the new Scripting features are only supported when using the new script compiler.
- Optimization to the bytecode generation: same scripts may now work faster at runtime.

Scripting:
- Support for having regular structs inside any structs (regular or managed); there's no nesting limit.
- Support having managed pointers inside managed structs.
- When declaring a pointer to managed struct you may now omit "*" sign.
- When writing struct's function's code you may now omit "this" keyword when addressing current struct's member (variable, attribute or function).
- Support for extender attributes.
- Support for multi-dimensional regular (non-dynamic) arrays. They may have any positive number of dimensions.
- Dynamic arrays now have Length pseudo-attribute used to retrieve their length.
- Global variables may now be declared right after struct's or enum's declaration, between the closing bracket and closing semi-colon.
- Functions now may call any other function from within same script, regardless of their order of declaration.
- Compiler can now evaluate integer or float expressions at compile time whenever result is actually constant and can be calculated at compile time.
- "const" keyword now may be used to define compile-time "int" and "float" constants.
- "readonly" keyword now may be used to declare non-modifiable variables (local or global) and function parameters.
- Added "fallthrough" keyword, which is used to hint that switch's case does not require a break statement. This is only to clarify coder's intent and prevent compiler's warnings.
- Support pre-increment and pre-decrement operators (++x, --x).
- Support bitwise negation operator (~x).
- Support addressing members of the function return values in one expression. This lets chain multiple commands including function calls, e.g. GetObject().MyVariable...and so on.
- Two sequenced string literals ("text" "text") are now automatically concatenated.

Script API:
- Most of the deprecated API is now removed completely, except those that have no equivalent.
- Added SCRIPT_EXT_AGS4 macro which tells whether extended script syntax is supported by the compiler. This may be used to know whether the script is being compiled by the old or new compiler.
- Added SCRIPT_EXT_NESTEDPOINTERS macro which tells whether nested managed structs are supported by the compiler.
- Added Joystick struct, meant to work with joystics and gamepads in script.
- Added BlendMode enum.
- Added Character.BlendMode, GUI.BlendMode, Object.BlendMode, Overlay.BlendMode.
- Added Character.UseRegionTint and Object.UseRegionTint, deprecated Character.IgnoreLighting.
- Added Camera.Rotation, Character.GraphicRotation, GUI.Rotation, Object.GraphicRotation, Overlay.Rotation.
- Added DrawingSurface.BlendImage() and DrawingSurface.BlendSurface() functions.
- AudioChannel.Position and PositionMs no longer return a very large value while skipping cutscene.
- Removed "hasAlphaChannel" param from DynamicSprite.Create() and CreateFromExistingSprite().
- Removed HasAlphaChannel property from DialogOptionsRenderingInfo.
- Removed "transparent" param from Overlay.CreateGraphical() and CreateRoomGraphical().

Engine:
- Support joystick and gamepad input.
- Implemented more accurate Character movement. The movement direction is now more precise and diagonal movement speed no longer may exceed MovementSpeed setting.
- Animated buttons now display flipped frames correctly.
- (possibly) Fixed characters sometimes keep walking animation for a short time after arriving to their destination.
- Added "--print-rtti" command line option which prints script RTTI table to the log.
  (RTTI stands for "runtime type information", and is used for handling of certain advanced script features, such as nested managed structs.)

[Crimson Wizard]

KNOWN ISSUES

[FIXED]1. Some room backgrounds may become fully transparent after the project import. Their RGB colors persist, but alpha channel becomes 0 in every pixel.
The workaround currently is either to reimport background from the original source, or to open a bg png in the Rooms dir and fill alpha channel with opaqueness (if you graphic editor allows that).


2. There are couple of functions which now have less arguments compared to the previous versions of AGS.

These functions are:
- DynamicSprite.Create and DynamicSprite.CreateFromExisting, they no longer have "has alpha" argument, as in 32-bit games all sprites are considered to have usable alpha channel now. (This is actually under question, and may change again to e.g. have an argument that defines a pixel format)
- Overlay.CreateGraphical does not have "transparent" arg, as it was useless all the way.

This is an unusual case (commonly arguments are added). This may cause script errors if you import a project or a module.

The solution for a quick fix, when you don't want to manually fix all these function calls in your game, is to create a script module on the top of the scripts list, and place helper extenders there which wrap actual function calls, like this:

Code: ags

DynamicSprite* Create(static DynamicSprite, int width, int height, bool unused)
{
    return DynamicSprite.Create(width, height);
}

static DynamicSprite* DynamicSprite.CreateFromExistingSprite(int slot, bool unused)
{
    return DynamicSprite.CreateFromExistingSprite(slot);
}

Overlay* CreateGraphical(static Overlay, int x, int y, int slot, bool unused, bool clone)
{
    return Overlay.CreateGraphical(x, y, slot, clone);
}

Overlay* CreateRoomGraphical(static Overlay, int x, int y, int slot, bool unused, bool clone)
{
    return Overlay.CreateRoomGraphical(x, y, slot, clone);
}

[Eon_Star]

Hi,

I tested this version. When in room editing window the background PNG was not visible (Gray Background). In the game window however it was ok. Thanks for your efforts.

[eri0o]

Could you share the PNG?

[Crimson Wizard]

I tested this version. When in room editing window the background PNG was not visible (Gray Background). In the game window however it was ok. Thanks for your efforts.

Hello, this is a known issue that I'm currently looking at. The background does not actually become grey, it becomes fully transparent with alpha channel = 0. It's visible in the game because the engine forces room bgs to be rendered opaque.

The workaround currently is either to reimport background from the original source, or to open a bg png in the Rooms dir and fill alpha channel with opaqueness (if you graphic editor allows that).

[Eon_Star]

Thank you Crimson Wizard. I think this version will be great.

[Crimson Wizard]

The fixed update may be downloaded here:
https://cirrus-ci.com/task/5237373961764864

[Eon_Star]

I did dowload the fixed version. Keep up the good work and stay healthy.

[Crimson Wizard]

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

Contains updates and fixes from 3.6.1 Beta 3.

Other changes:

Editor:
- Fixed room backgrounds with color depths < 32-bit (like 24-bit rgb) could display fully transparent in the Editor after project upgrade.
- (possibly) Fixed incorrect "script was modified externally" message occuring when it was not actually modified externally.

Compiler:
- Fixed `++` and `--` operators could be used wrongly as a binary op (like `a ++ b`), and compiler did not detect any error.

Engine:
- Fixed character/object scaling not working at all, because of a typo in code.

[Crimson Wizard]

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

Contains updates and fixes from 3.6.1 Beta 6.

Other changes:

Common:
- Removed support for '[' as a linebreak character in text.
  Please use a standard '\n' from now on.

Editor:
- Support loading PNGs with transparent chunks as Room Masks.

Engine:
- Fixed flipped button frames displayed without transparent parts.



You might have noticed that there was not much of new additions to AGS 4 updates besides than merging 3.6.1 updates in. There are currently couple of major changes in works:
- Translation migration from classic AGS TRS format to a more widespread PO format, which should make working with translations safer, and make adding further translation features easier.
- Joystick/Gamepad script API.

I believe these two will be introduced in the next AGS 4 Alpha update.

[Baguettator]

Just a big congrats to all of you who are still working on this incredible free  and rich program !! I will test AGS 4.0 as soon as I can !

I have a question that could be (or not) a suggestion for AGS development : is it possible to create during runtime new buttons or GUICOntrols or things like that ? I mean : the game could manage new buttons that have not been created in the editor, but created during playing the game ?

My idea is that I'm making a "map editor" for something, so I have to place tokens (tiles, events, starting zones, objectives, characters etc...) to create a map. I can't imagine doing this another way than using GUIControls (or characters, or room objects) to represent tokens, to easily be able to manage clicks on them to delete, rotate, move etc...

The problem is that it will necessary limit the possibilities, the number of tokens "available" because I can't have infinite GUIControls. I have to create 100 GUIControls, and I can't add more than 100 tokens for a map (for example).

So, the idea would be to be able to create new Buttons in runtime. Each time I create a token, it creates a Button that could be a copy of another one (for the scripts functions attached to them for example), and then act on them (change the graphic, the orientation etc...).

Is it a limitation of AGS Engine ? Or a limitation of engines in general ? Or something like that could be possible ?

Probably my question is stupid, as I'm not an expert like you. But perhaps...

Also, I hope my post is at the right place, as I thought it was a "development consideration", but sorry if it's not the case, I can delete it if necessary.

Anyway, congrats for AGS workers that make it possible to have such a program !

[Crimson Wizard]

Is it a limitation of AGS Engine ? Or a limitation of engines in general ? Or something like that could be possible ?

This is the current limitation of the AGS engine. But frankly this is more of a design issue rather than a technical one. In other words, it's not too hard to create a button at runtime, it may be complicated to logically bind this with how the engine treats the objects created in the editor.
This is further complicated by AGS not supporting linking functions to events in script, which means that even if you create a button in script, you won't be able to receive click events from it.

Supporting doing this is theoretically in TODO (for a long time).

My idea is that I'm making a "map editor" for something, so I have to place tokens (tiles, events, starting zones, objectives, characters etc...) to create a map. I can't imagine doing this another way than using GUIControls

For the purpose of having unknown number of objects on screen there are 3 existing options:
1. DrawingSurface. This is a traditional method. You may drawing anything, but you will have to store all the object properties in your custom structs, including their positions.
2. Overlays. They are not limited anymore since 3.6.0. The benefit of these for the map editor is probably that you don't have to script redrawing a map when moving/deleting these, and they may use fast scaling & rotation (may be not exactly important for the map editor).
3. Using a pool of objects. Will limit number of simultaneous objects on screen, so probably not the best solution for the map editor.

With the first two options you have to detect clicks yourself. How this is done depends on your use of them. If this is a "tiled" map editor that might be rather simple, since you can calculate which tile the player clicked on and proceed from that. Overall this is a big technical topic, which I won't like to cover in this forum thread.

[Snarky]

@Baguettator, you may want to check out the ImGi module, which allows you to create GUI Controls in script (though they're not "real" Controls, but a reimplementation using Overlays). Though since what you're trying to do isn't actually to create a GUI, you may be better off just implementing what you're trying to do yourself, as CW explains.

[eri0o]

Hey, my ImGi module started as using Overlays but it quickly changed to be based to Drawing Surface with it's own hashed-dirty-rects system due to the limitations of Overlays at the time - like, there was no sorting of overlays at the time.

There is still one limitation that makes it rather tricky to rewrite it as hardware accelerated that is there is no clipping in an Overlay, and this makes something like scrolling a bit hard to do - like, I would need to make things hardware accelerated and selectively degenerate things as software drawn when they were clipped, which is a bit hard. If there was some hardware accelerated clipping, than it could be done easier. Alternatively, some sort of Camera system in the GUI space would also work - although much harder to manage from a scripting perspective, "clippable " overlays would be far easier.

[Baguettator]

Thanks for answers ! I didn't expect that it was a limitation of AGS engine, but something not too hard to update. So good news ! Even if it will take time to be achieved, I think the best thing is to wait and sometimes push the idea to ags developers

Thanks for the solutions and for erioo's module, it's what I thought about (I've never worked with overlays, but sounds great !). For now I'll stay with Guicontrols, as I have already implemented many things with it and it's easier to script. When Ags will be ready... I'll change

So, good news ! I hope to test AGS 4.0 soon !

[Baguettator]

EDIT : Crimson Wizard, you told that it's not complicated to create a button at runtime ? The biggest problem to link it to functions in script ? But does that mean that we could have AGS able to create buttons at runtime, and then we could interact with buttons using the "mouse_onclick" function, something like :

Code: ags

function onmouse_click ()
{
  GUIControl *g=GUIControl.GetAtScreen(mouse.x, mouse.y);
  if (g.Graphic==12)
  {
    //I know which token it is, so I do that
  }
}

It could be as simple as it, waiting for a long time if one day it could be possible to do more complex thing, attaching functions dynamically to controls by script. But if that simple case could be possible... could be great, isn't it ?

[Crimson Wizard]

EDIT : Crimson Wizard, you told that it's not complicated to create a button at runtime ? The biggest problem to link it to functions in script ?

That is not the first problem. There's a number of things that have to be decided and changed in the engine to make supporting this convenient. I would have to go into more detail to explain, but I do not want to do this in this forum thread.

But, besides, if the button is not bound to events, then what's the point of creating it? It's easier to create an overlay.
Overlays are simpliest graphical objects in AGS, they are fast, flexible, may exist both on GUI and Room layer, and already support more graphic effects than buttons (e.g. scaling in 3.6.0 and rotation and blend in ags 4). This actually makes them superior to buttons, at least at the moment, if you excuse the lack of an automatic reaction to clicking.

You may do almost same thing in on_mouse_click with overlays as you do with buttons, except you need to write your own GetAtScreen for them.

[Baguettator]

Yeah, but scripting an overlay to detect mouse clicks would be harder, isn't it ? I thought having a button is easier to detect that it's a button and I click on that, even if it doesn't have any function linked to it.

[Crimson Wizard]

Yeah, but scripting an overlay to detect mouse clicks would be harder, isn't it ?

Supposedly, but that's a typical problem, and has its solutions for a script.

EDIT:
It's also possible to add GetAtScreenXY for overlays too, I did not add that at a time because I wanted to keep its API simple, but guess it was a wrong idea.
The problem this is coupled with is that currently GetAtScreenXY works simply by iterating over all objects of the type and testing the coordinates. This will become slow with the large number of objects created, so some kind of an optimized algorithm would be prefered, like space partitioning. But same goes to anything else that would support dynamic creation.

[vga256]

I am beginning AGS4 testing on a game that requires the new features offered by the new data structures. Please let me know if there are specific features or functions the team would like to see tested as I work.

Although I know this is not the proper place for this - I am also among those who needs support for runtime-generated/dynamic GUIs. Scripting workarounds to emulate this (e.g. spawning dozens of empty GUI elements and then showing/hiding them at runtime) is currently extremely painful as a developer.

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

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