AGS 4.0 - Alpha 21 for public test

[Crimson Wizard]

The crash occurs after I click or press a key to exit the display function. Until that, the crash doesn't occur (don't know why, maybe because SaveGameSlot works at the end of the script..?).

Indeed, saving is done after the end of the script, because AGS cannot save inside a script function.

I will try the build...

[Crimson Wizard]

The crash occurs after I click or press a key to exit the display function. Until that, the crash doesn't occur (don't know why, maybe because SaveGameSlot works at the end of the script..?).

https://drive.google.com/file/d/1VJHiVDGWGeNZVHdjKEu7njZaRNQEYcMG/view?usp=sharing

I found this happens if you have zero-length dynamic arrays in script.
The fixed engine build will be available here:
https://cirrus-ci.com/task/6628039687143424

[Baguettator]

Hi, I just tried to save/load with the new version, and I got a crash again. It seems something linked to the engine, and not something linked to my code.

An exception 0xC0000005 occurred in ACWIN.EXE at EIP = 0x00572656; program pointer is +6, engine version 4.0.0.15, gtags (0,0)

Here is the updated compiled game, with the crash log inside.

https://drive.google.com/file/d/174ekAxu5V3ci3FdxvMUdbWUBGJUOPODh/view?usp=drive_link

You can try the same Ctrl+N to make save called "try", and load it by clicking on the "CHARGER" button you can see in the menu.

The ONLY thing that has changed is that I used that at game_start :

SetGameOption(OPT_SAVECOMPONENTSIGNORE, eSaveCmp_Audio + eSaveCmp_Dialogs + eSaveCmp_GUI + eSaveCmp_DynamicSprites + eSaveCmp_Plugins + eSaveCmp_Cursors + eSaveCmp_Views);

If I disable this function, the loading doesn't crash.

Let me know if you find something !

[Crimson Wizard]

Hi, I just tried to save/load with the new version, and I got a crash again. It seems something linked to the engine, and not something linked to my code.



The ONLY thing that has changed is that I used that at game_start :

SetGameOption(OPT_SAVECOMPONENTSIGNORE, eSaveCmp_Audio + eSaveCmp_Dialogs + eSaveCmp_GUI + eSaveCmp_DynamicSprites + eSaveCmp_Plugins + eSaveCmp_Cursors + eSaveCmp_Views);

This is happening because when restoring a game without dynamic sprites, all DynamicSprite objects in script are invalidated and assigned "Graphic" to -1. You should clean them up to null after restoring a save, or recreate (if that's suitable).

The crash itself occurs when script is trying to get some property from a invalid dynamic sprite (Width or Height).
Of course the engine must not crash like that. I forgot to add safety checks in the engine to prevent this from happening, so must do that now.

EDIT:
Actually, I found that I made the "invalidation" wrong. When the DynamicSprite is deleted (by calling Delete) it assigns Graphic to 0, which is a "safe placeholder". So I might just do the same for consistency.

[Baguettator]

OK, that's what I thought about. I'm currently bugtracking that.

What I'm currently doing is rebuilding the dynamicsprites in the "on_event" function with the restore_game argument. I presume that when you will fix it, if objects hadn't got their dynamicsprite on resume_game, their graphic property will be set to 0 ?

[Crimson Wizard]

So, after fixing this in the engine, the game does not crash in the same place, but it errors later with a script error, because it tries to do something with "deleted" dynamic sprites. So the script has to be fixed in any case.

Here's a fixed engine, I built and uploaded it directly to dropbox this time to speed things up:
https://www.dropbox.com/scl/fi/eh2fa6kvow838hu0pfnxs/acwin-4.0.0.15-saverestorefixes.zip?rlkey=yctz3kdyk7oaazzu68ce1fybn&st=vmvod30f&dl=0

What I'm currently doing is rebuilding the dynamicsprites in the "on_event" function with the restore_game argument. I presume that when you will fix it, if objects hadn't got their dynamicsprite on resume_game, their graphic property will be set to 0 ?

No, the other objects are not changed. Only DynamicSprites are invalidated, marked as "deleted".

I don't know if that's correct to recreate all the dynamic sprites on restoring a game. I would restore only those that are required for the current scene.
But then, in a tabletop simulator like your game I would use a custom save system anyway. That would prevent such problems completely.

[Baguettator]

Thanks Crimson !

My question was : if I don't save the dynamicsprites, is it correct to rebuild them (all the needed ones of course) in the on_event function with the "restore_game" argument ?

For me it's important to save all the variables, because they are a LOT in my game (it's not only placing tokens there and there), and I think AGS is doing that better and faster than I would do with script. And moreover, it's not needed if AGS already can do it. The thing is just I don't want 300Mo save files, so I exclude everything that's not needed, especially dynamicsprites. I'm just thinking of what's the right timing to rebuild them, and I thought on_restore_game should be the good one.

[Crimson Wizard]

My question was : if I don't save the dynamicsprites, is it correct to rebuild them (all the needed ones of course) in the on_event function with the "restore_game" argument ?

I suppose that on_event with eEventRestoreGame is a proper place.

For me it's important to save all the variables, because they are a LOT in my game (it's not only placing tokens there and there), and I think AGS is doing that better and faster than I would do with script. And moreover, it's not needed if AGS already can do it.

I don't have a full knowledge of your project, but I doubt you need to save all of them, judging by my own experience. There are likely ones that you don't need to save/restore. It's all about dividing the game into what is a "mission state" and what is not. It's also quite possible that having custom save system will make managing resources like DynamicSprites easier, since they will not be invalidated by restoring a save.

Anyway, this is a big separate topic, and I won't go there further. I just think that it's a mistake to rely on AGS save system if this is not a standard adventure game.

[Baguettator]

At least, I'm improving my game with the new features that allow to exclude many no needed things into the savegames. It's the first step, and little by little, I will see if it's more convenient to make a real custom save system. Thanks for the suggestion

I thought about something to suggest, for AGS4.0, if it's not already implemented (perhaps I ignore it !), but it could be a quality of life feature to allow excluding some strings to be added into the translation files. I don't know if it's a nice feature, but I know that debugging strings, or many strings that sometimes don't need to be translated (like characters' names) don't need to be in the translation file, and it could lower their size a bit or a lot.

[Crimson Wizard]

@Alan v.Drake , @Snarky , in regards to drawing transparent color on DrawingSurface,
I implemented 3 new blend modes: Copy, CopyRGB and CopyAlpha:
https://github.com/adventuregamestudio/ags/pull/2695

I've also been considering Snarky's suggestion about having a DrawingSurface.Clear* function pairing each Draw* function, but decided to postpone this and see if it works with BlendModes. Adding the functions is possible, but we'd have to add one for each operation, and keep adding these for each new drawing method in the future, which seems mildly annoying.

Plus I found another use for "Copy" blend modes: complementing/replacing CopyTransparencyMask function, and also cutting holes in GUIs with blended controls, which might allow more hardware accelerated tricks (see PRs description for details).

[Crimson Wizard]

@Baguettator , this is an experimental build, which adds a new way to draw transparent geometry on DrawingSurface:
https://cirrus-ci.com/task/4560032798343168

if you'd like to test this out,
it requires to set a BlendMode property for this, like:

Code: ags

ds.DrawingColor = COLOR_TRANSPARENT;
ds.BlendMode = eBlendCopy;

[zoeytrope]

Hi! Hopefully I'm doing this the right way.

Since update 19 (including the updated versions posted here), I've been having issues with dialog scripting, and I'm unsure if this is a bug or a scripting change since update 18.

Whenever you start a dialog (eg. dDialog1.Start()), it only runs the dialog script with ID 0 instead of correct dialog script. Also, instead of responding to "stop", "goto-dialog dDialog2", etc., it returns to start of dialog script with ID 0.

So basically if you start any dialog, it runs the script with ID 0, and loops that script with no way to exit.

Thanks, and apologies in advance if I simply missed something really silly!

Sample project to illustrate: https://drive.google.com/file/d/1HjBseBUYzGSYRTrR0MkjO4ds54Aw0D1q/view?usp=sharing

[Crimson Wizard]

@zoeytrope there was a bug which caused engine to discard any script function return value.

A fixed build may be downloaded here
https://cirrus-ci.com/task/5294271038750720
(it will be ready in ~30 mins after me posting this)

[Crimson Wizard]

A demo of what's coming in the next AGS 4 update:
An example of Button having a BlendMode "CopyAlpha", moving across GUI:



Previously this would require to do a mix of operations over dynamic sprite, with the use of CopyTransparencyMask function.

[Baguettator]

Really nice feature, congrats Crimson Wizard ! I'm unable to test it right now because I want to fix things in my game before updating AGS, but it's really beautiful !

[Crimson Wizard]

I forgot to post this, this is a new temp build which contains these new modes, in case somebody wants to try:
https://cirrus-ci.com/task/6640724495564800

This build brings back an ability to draw transparency to drawing surface by replacing pixels.
This is done by setting "DrawingSurface.BlendMode = eBlendCopy", which will copy the color to destination instead of merging with the underlying color.

There are also 2 accompanying modes: eBlendCopyRGB and eBlendCopyAlpha, which copy either only RGB part but keep surface alpha, or copy only Alpha but keep surface color. These may be used, for example, to make part of the surface half-translucent while keeping its current image, or vice versa recolor part of the surface while keeping its translucency.

[Baguettator]

OK, perfect !

Now, it's only missing gradient implementation

[Crimson Wizard]

Now, it's only missing gradient implementation

What is that?

[Baguettator]

I'm not sure if it's the right word, but by "gradient" I think about "dégradé" in french. Like a slow transition from a colour to another one. AGS could need this kind of feature (but could be tricky to implement, I don't know !)

Anyway, I think there's a problem with the FadeIn function. I used it for debugging purpose (to be able to see the "display" function during a room transition, because my transition is fadein/fadeout, so I placed a "fadeIn" function during the "room_onload" function), and just after the fadeIn, my mouse is not visible at all. Is it an engine bug ? Sorry, I can't give more details or try on a dummy game at that moment, I'm just sharing the info now.

[Crimson Wizard]

I'm not sure if it's the right word, but by "gradient" I think about "dégradé" in french. Like a slow transition from a colour to another one. AGS could need this kind of feature (but could be tricky to implement, I don't know !)

That is trivial to do in script, just make a for loop from one color to another, and draw lines.

Anyway, I think there's a problem with the FadeIn function. I used it for debugging purpose (to be able to see the "display" function during a room transition, because my transition is fadein/fadeout, so I placed a "fadeIn" function during the "room_onload" function), and just after the fadeIn, my mouse is not visible at all.

"room load" event is not suited for any animations, because room is not supposed to be displayed at that time. Any animations, including screen effects, custom transitions and on screen messages should be done in "after fade in".