Messages

I guess if there is an already speech or display call, when the executor wait time expires, they still would to wait for the blocking thing to end so it can spawn a new blocking thing (like Display("RunCoroutineTest: 2");).

It depends on how the coroutine update is run, if they are made to run during blocking actions or not.
There's also a question of whether there should be a difference between coroutine started from the normal event and from rep-exec-always.

Edit: actually I am not sure I get this, does doing this would require a WalkAsync to wait for the blocking walk to finish or using regular Walk with async would work? The issue I see here is a "cancel" action would still cause the next line after the walk to execute.

WaitAsync is the most primitive implementation for the test. Normally this would require having all the functions that start actions to return "action identifier", and let coroutine wait for them.

It also should not happen by the function call itself, but by some keyword over function call's return value.

So, speaking of coroutines discussed above in this thread (among other things),
I've been rewriting the script executor class for the AGS 4 engine, for unrelated reasons, when it came to me that these changes add a potential to implement coroutines.

So I did a very quick and dirty test, and although done wrong, it works in practice (with lots of restrictions).

https://github.com/ivan-mogilko/ags-refactoring/tree/experiment--dumb-coroutine

Normally this would require new script syntax and keyword(s) (like "yield", "async" or aforementioned "waitfor"), but here I did not want to bother with compiler so added WaitAsync(loops) function that converts current script into "coroutine".

In principle it works like this:

- WaitAsync is called, it sets "async wait counter" and asks executor to suspend;
- script executor suspends current script thread and returns;
- engine checks execution result, finds that thread was suspended, copies its full state to the special "coroutine thread";
- game continues to run as normal, with all the player input, GUI, etc;
- engine updates "async wait counter" on each game tick;
- as soon as that reaches zero, it tells script executor to run the previously saved "coroutine thread";
- more suspends are possible, coroutine thread may be suspended again and again after each start, until it finishes.

The current implementation cannot have multiple simultaneous coroutines, any new one will overwrite previous completely, but that's just because I was lazy. Normally it should have a list of wait counters mapped to coroutine threads, or something similar.

Example of script that I used to test this:

Code: ags

function RunCoroutineTest()
{
    Display("RunCoroutineTest: 1");
    WaitAsync(60);
    Display("RunCoroutineTest: 2");
    WaitAsync(60);
    Display("RunCoroutineTest: 3");
    WaitAsync(60);
    Display("RunCoroutineTest: 4");
}

function on_key_press(eKeyCode key)
{
    if (key == eKeyW) RunCoroutineTest();
}

So what happens here is that after you press W, the sequence of Displays is going to run one by one with delays, but at the same time the rest of the game goes on normally, character walks, GUI works, other scripts run, etc.


EDIT:
Maybe we should start a separate forum thread for this, as the original question was about interrupting blocking action rather than scheduling asynchronous actions.

The "custom portrait placement" that Snarky linked is a way to automate the placement.

But if above will not be enough, for a fine manual tuning there's a direct access to the portrait object:
https://adventuregamestudio.github.io/ags-manual/Speech.html#speechportraitoverlay

1) I have seen that AGS 4.0 is not displaying "perfectly" sprites : it seems sometimes (or always ? hard to say), there is a line (1 pixel width) that is not drawn. Also for ListBoxes' or TextBoxes' perimeter, not all the lines appear.

Does this happen always, or in a particular case? Can you give a precise example, like, which object, what are this object's properties (size, position, graphic settings)? Does this happen with any graphic driver or specific one?

2) when you update the translation file, how it works ? If I have already a translation file, and then I delete some lines in my scripts : will the deleted lines be kept in the update ? I remember in 3.6, only the new lines were added (like a File.Append), but I had to delete manually in the .trs file the lines that weren't anymore in my game

As far as I know, nothing has changed in this regard compared to 3.6.

Since I don't want to use Beta or Alpha versions of the software, I'm not really aware of all the plans you guys have for AGS 4, so that's why I asked.

Well, yes, we do not have that in any milestone at the moment.

My initial thought was about parallax visuals only, but seeing how the conversation goes, the full support would require multiple interactive mask layers as well, and possibly rethink of how room itself is organized, i.e. what defines room's bounds for instance. In the past there has been a proposal to remove a hard restriction tied to the background image's size completely, and let display any range of coordinates, while background becomes sort of an object in endless space. That is another thing to the list. (Or perhaps the first one to do)

If this was in response to me, what I was trying to illustrate with the example image was that you might want a parallax layer where only particular regions would act as hotspots, or you have multiple different hotspots in each layer, etc. You can't easily do that with objects—you'd have to split each layer into separate objects.

I think the last sentence has a contradiction: yes, you have to split a layer into multiple objects, but no - that still means it is easily done with objects.

Personally I assume that goes without saying: a layer should potentially consist of multiple pieces.

I fully understand that you can create parallax effects using different objects today. However, my question was if there were any plans to implement different layered backgrounds (that could have transparency) in AGS 4. What I got from the various replies in this thread is that there currently are no such plans.

Excuse me, but then I did not understand your question correctly. Please tell, what do you imply by "layered backgrounds" precisely?

AGS already sort of can have "layered backgrounds with transparency", which is if you use objects and room overlays.
Did you also mean to have layered masks along with these backgrounds maybe? Or anything else?

@Snarky for complex scenarios, similar to what you describe above, AGS would require to have multiple layers for hotspots, walkable areas etc, where Characters could switch between them.
I recall that tzachs was implementing a similar thing in his MonoAGS, and I even made a tiny demo game in MonoAGS which featured "dolly" + parallax effect. This may be found somewhere in MonoAGS forum thread. If I remember right, walkable areas were just an object, and you could have multiple of them created dynamically (although my memories of MonoAGS are becoming vague today).

I see you using the word "Opaque" a lot, and so more making a note here to remind me when making docs, alpha is actually a measure (or a value?) of Opacity. Throughout AGS Script API we use Transparency, which is the inverse. A 100 value of Transparency is a 0 value of alpha.

BTW there's a ticket that proposes to change Transparency to 0-255 alpha too:
https://github.com/adventuregamestudio/ags/issues/2549

Also with alpha in the color a lot of things that used to be blit can't be blit if the alpha is not 255.

This is a matter of providing a separate blitting function that supports alpha blending.
OTOH we may state that we do not support it everywhere for starters.

We could use the plain int approach, this could work nice with the hex assignment. 0xaarrggbb or 0xrrggbbaa or just 0xrrggbb depending how the colors are thought through.

I've been thinking about 2 approaches in regards to plain int values.

1. Have all colors treated uniformly as ARGB in all properties and arguments.

That will be most consistent, and simple to implement, but will make 0xFF... prefix mandatory for opaque colors when you define the color by hand, which may be seen as annoying by some, and be prone to user mistakes.
Two more notes here:
- Value 0 will be the easy way to set "transparent color".
- Alpha has to be in highest bits, because 0xRRGGBB may be cast (assigned) to 0xAARRGGBB, but cannot be cast to 0xRRGGBBAA (will require value conversion).
- Majority of users can just use Game.GetColorFromRGB / Game.GetColorFromRGBA functions to form colors; where old one will always return opaque color (alpha 0xFF).

--------

2. Have separate properties for RGB and ARGB.

After some hesitation, I wanted to propose this as an alternative to having a Color.RGB/ARGB syntax.
The reasoning here is that in majority of cases users will likely want opaque colors, and specify alpha in relatively very small number of situations.

The idea is to have a "argb" property pair for each xColor property. For example:
- GUI.BackgroundColor
- GUI.BackgroundColorA
- Button.TextColor
- Button.TextColorA
- DrawingSurface.DrawingColor
- DrawingSurface.DrawingColorA
etc

where Object.Color would interpret positive integer values as RGB, and let's say "-1", or any invalid value would mean "transparent color".
And Object.ColorA would interpret any value as ARGB.

The downside here is obvious duplication of each Color property (but I think there are not too many of those).
There is also a room for mistake, where one would try to assign full argb to rgb property.

The upsides are:
- This allows to restrict certain things to no alpha support, and make alpha support more explicit.
- Users are not required to remember to put alpha 0xFF when they define opaque colors.

There's a remaining question of colors as function parameters though.

I think the problem was "per GUI" : the first images you generate within the same GUI will have problems (invisible), and less and less problems for the followings. That's why the images became more and more visible, and only 1 or 2 of them were fully displayed.

The problem I fixed was loaded sprites being invisible. But I cannot explain other things.

I mentioned in the ticket, what if we do that Color managed struct, all these properties are now this type, and things that need color properties would instantiate these managed structs and hold a reference internally. Then we can either make these readonly (so people must use the properties) or handle the pointer assignment as way that only copies the values (but not the pointer, or people could pass the same pointer to multiple properties and get confused when changing one property change another).

Then we could do obj.Color.RGB = 0xRRGGBB or obj.Color.ARGB = 0xAARRGGBB (or obj.Color.RGBA = 0xRRGGBBAA, and however we handle it, we hide it internally (including any mask color necessary).

I've been thinking this over for several hours, and while I like the syntax, I am much concerned about the implementation particularly in AGS, and thus became reluctant to do something like that. If this was a new engine, or a different script language, then maybe it would be easier or better justified...

There are multiple issues here: the color storage in dynamic memory that has to be serialized, how game objects will be accessing these, will the Color instance duplicate color values from object's own data or read/write directly to them?
There will be a use of Color in object properties, but also in user script, then likely it has to contain all data within itself.
Then, AGS engine's code currently has a number of problems in its organization, which may make it inconvenient to bind a game class to a separate managed object. An example is GUI classes that do not have any proper "runtime" class equivalent yet which would allow to handle access to managed data. We'd need to reorganize them first prior to doing something like that.

Then, if we replace properties, then should not we also replace function arguments? There is "color" arg in some functions, like Overlay.CreateTextual. Game.GetColorFromRGB would need to return Color struct.

An idea of having separate DrawingSurface.DrawingColor as integer just for the sake of maintaining performance, while having a practical purpose, looks bad for consistency of API.

If script API uses Color struct, then users should be able to store colors in the same struct too, to keep things smooth.
But then another big inconsistency is going to be color assignment: as you say, when stored in objects they should not be shared, so assigning a Color reference to object's property will act as a copy. But if users use Color struct in their scripts, these will not copy when assigned but share a reference? Which will lead to mass confusion. So this might require designing a specific syntax approach. I'd even say: an ability to pass and assign PODs (plain structs) could come handy.

Overall this means that implementing such approach would require good amount of effort, while breaking user scripts and requiring them to change some habits.

Repeating myself, if this were a new engine then this could be justified. But what do we gain with such overhaul in the existing one? It's the ability to set "transparent color", or provide "alpha" value to color properties, where latter is not normally required alot.
Looking at the cost / benefit relation here makes me quite doubtful.

Maybe this idea could be planned to be looked into again after a bigger refactor of the game classes in the engine, as a part of the big script api overhaul, where other complex things, such as various transformation and graphical properties, would receive same change.

The main problem for me is the dynamicsprite not rendering correctly. Hope you will fix it as soon as possible !

I found what was wrong with some sprites not visible after loading, but I don't know how to reproduce the other problem where sprites have lines on them.

Does this happen with particular sprites (which ones?), or after you do something to them?

EDIT:
here's the temp build which has sprite loading fixed:
https://cirrus-ci.com/task/6201304671846400

EDIT 2 : new problem I encounter in AGS 4. If I attach a function On_Click on a button called "Objectif", the function is by default called Objectif_OnClick. If I rename it, let say Fouille, then in the editor I click in the "..." button of on_click function in the right panel of the gui's window (with the Objectif button selected, so in this box there is the name of its onclick function, so in my case it's written Fouille), the editor creates a new function called Fouille. Previously in AGS 3.6, he knew that there was a function called Fouille, and he didn't create a new one, he jumped to the right function directly.

@Baguettator  could you please post step-by-step instruction on how to reproduce this problem? At first I thought I got it, but trying now it works fine, so maybe I am not doing what you were doing.

Whatever is done has to be throughly tested in the hard case that is a game with a linear interpolation, to see if the border of sprites are affected since the ticket with all the changes written impacts how sprite importing would happen.

I don't understand, how does that ticket impacts sprite importing?
I re-read it, and I do not see anything mentioning sprite import...
EDIT: i found something in comments, is it about sprite->texture conversion?

In any case, I am not suggesting to implement that ticket as-is. It may be split apart and done in steps, discussing and testing every step separately.

Above looks alright on its own (in api sense), but naturally my concern is that this will break all the people scripts... If that's fine, we could try that approach.


EDIT:
Also, I am mentioning this since you have brought the script function speed before, this will make setting colors somewhat slower, because that would require 2 function calls:
- get_Color - that returns a pointer to Color struct
- set_RGB - that sets value as rgb.

Would there possibly be a need for three versions of the color picker?

- 24-bit (RGB) for colors that must be fully opaque
- 24-bit/transparent for colors that can be opaque or not drawn at all
- 32-bit (RGBA) for colors that can have alpha-transparency

I am currently not certain if it is necessary to have all 3 variants and not just the fullest one.
But besides (or rather - before) the editor GUI there's a problem of
a) saving this value in game data. Right now all the colors in AGS 4 are interpreted uniformly as R8G8B8, the uniformity keeps things simple.
b) having this value in respective script properties.

Because even if you take just the single transparent color as an addition, it's not im clear how to incorporate it in the existing system without treating alpha bits as alpha. I.e. classic 255,0,255 color may be opaque too.

I had a ticket open (https://github.com/adventuregamestudio/ags/issues/2525), but it received a mixed reaction from other devs. I suggest that we need to come to a conclusion on it.

EDIT: I think (and noted in the last comment to that ticket), that I put several separate things in it by mistake. Maybe these things should be disconnected and dealt with separately.

[Perhaps]

Also, not a great problem, but I noticed that if selectedBackgroundColor=0; 0; 0 for a ListBox, it makes it transparent. Before, in AGS 3.6, it was black (as intended).

This is a known problem, but I must clarify: color 0 is treated as transparent by SelectedBackgroundColor property.
The reason why "black" color worked before was that it was written in palette index other than 0 (16 to be precise), but it's not possible to do now in AGS 4, where colors in 32-bit games must be written as 32-bit RGBs.

There's no other way around this than to select slightly non-black color at the moment.

I do not know what the actual fix should be, as there's no way to select "transparent color" in these properties. Either we have to implement that somehow, or maybe there could be a separate property that sais "show or not show the selection".

Personally, I'd prefer selectable transparent color, as "selection" awhole may involve multiple things, not just the bg color, while user may want to have front color for selected items, for instance, but not bg color.

EDIT: Perhaps having 0 color be black in 32-bit would work as a quick fix. Because it's more likely that users want a bg color for selection. And if they want transparent color, they may assign the background GUI color. The only case when that won't work is if the GUI has a non-trivial background graphic...

By the way another reason I deleted my games was to tell you there was/is no personal interest involved, in case anyone is struggling to understand that.

One thing amazing about this is how you claim certain goal, but achieve the opposite impression. After every addition or edit to your post(s) your position begins to look worse.
And you still cannot avoid putting condescending remarks into your posts... I mean "struggling to understand" in this case.

What's my goal?

I was referring to your very previous post, I think it was stated pretty clear:

By the way another reason I deleted my games was to tell you there was/is no personal interest involved, in case anyone is struggling to understand that.

What's amazing is the number of people that need to try to defend one by one that AGS panel review is "perfect".

I never had an intent to defend AGS panel. I had an intent to point out that you act silly and you put insults vs other people in almost every your post in this thread.

By the way another reason I deleted my games was to tell you there was/is no personal interest involved, in case anyone is struggling to understand that.

One thing amazing about this is how you claim certain goal, but achieve the opposite impression. After every addition or edit to your post(s) your position begins to look worse.
And you still cannot avoid putting condescending remarks into your posts... I mean "struggling to understand" in this case.

The arrow near "Installer", the pop-up says "Download all files (ZIP)" when my cursor moves over it.

It sounds like you may be using some temporary download link, which points to a build server. This server deletes these builds after a while.

The latest AGS 4 version may be reliably downloaded using links in this forum thread:
https://www.adventuregamestudio.co.uk/forums/ags-engine-editor-releases/ags-4-0-early-alpha-for-public-test/