Messages

If AGS had only a single internal loop (like löve and a few other engines), the port could be done without using Asyncify at all, it would build faster, but above all, it would run faster - not a lot faster, 2 or 3 times of what it performs now.

Ah, but 2-3 times may be a massive difference (like 10 -> 30 fps, moving from non-playable to pretty playable). I wish I knew how impactful this is earlier.
Then this should be given a higher priority.

The web engine is naturally slower than the native one - there is a big refactor in AGS handling of loops that could unlock a 3x speed up in the web port but that's kinda it.

Could you please elaborate on this, as this is something I was not aware of? By "loops" I presume this has something to do with the game update handled differently depending on the state, but what makes web engine slower there?

Please tell, what is your game resolution?

Is there any transparent GUI covering the lower part of the screen? If so, then is it set as Clickable?

Adding a property that returns current level of the played audio file - that may be feasible, as a low-level API. In fact even returning a soundwave as array may make sense (similar to the suggestion of returning a pixel array of a sprite).
(EDIT: if i were making API, i'd probably add this to AudioClip. Although since audio playback calculates position in Ms, and levels are per sample, then there likely has to be a distinct property/function that returns an average of all samples for the given millisecond, or something like that.)

But I'm generally against adding complex built-in behavior based on this.

However, there may be another solution: use some tool to generate a sound timeline with these levels, put this as a custom data in your game, and use that in script instead. With this no additions to the engine will be necessary.

With this choice of colors and outlines, the game's art is clean and pleasant to eye .

[pressing Space button.]

I'm posting in this general tech section to be able to gather more opinions (maybe people look here more often than in "engine development"?)

I will have to explain something first, so please bear with me.

AGS historically has a hidden problem: its pathfinder and walking algorithm uses math with relatively low precision. This may result in rounding mistakes. What this means in practice is that under some circumstances the "movement direction" (vector) is slightly off, e.g. more towards X than Y (or other way). In such case the character may reach the X destination while Y destination is still few pixels away. This difference mostly depends on the walk length. By experiment, I think, in 320x200 area it rarely exceeds 2-3 pixels, but in larger areas (walking fully across a scrolling rooms, or walking around high-res rooms) it may actually be bigger, like 5+ pixels.

In AGS 4 Alan Drake had changed the math to use proper floating-point math, which seems to improve this situation (but I did not experiment much with that yet).

In the AGS 3.* branch I am afraid to make such change, because of the backwards compatibility with games, which may be scripted to depend on how character walks exactly (that is unfortunate, but ags 3 is still used to run these old games, as well as its scummvm port).

How is this issue solved currently in AGS (and for a long time):
When AGS finds out that one coordinate is complete, but another is not (for example X done and Y is still not reached), it starts waiting until character reaches Y, but also accepts a certain "mistake", in 2-3 pixels.
If character is already within 2-3 pixels from the destination, then it just stops. This makes its real stopping point inaccurate, but nothing else happens.
However, if character is further away, then it keeps "walking", but because the movement vector is still pointing in the same direction, usually it takes few moments for it to reach the proper Y coordinate.
This results in a buggy effect known as "walking in place".
Here's the actual example:

Spoiler

[close]

In the end, not only the character may end up in a slightly wrong position (2-3 pixels away), but there's a chance this above animating in place happening, which looks quite weird.

I guess that there may be various approaches to solve this problem. Currently I'm experimenting with a solution where engine will, so to speak, turn the walking vector to make it point right along the unfinished axis, while keeping its length (that means - walking speed), in order to reach the destination faster. At the same time, I removed the "mistake acceptance" completely, forcing character to always reach the requested destination.
This should make character make some extra short move, properly animating, but this may look more natural than just moving legs in place.

Now, the reason why I explain all this here, is that a result of this solution is that the character may make a kind of a "final step" in a slightly different direction in the end. And I've been wondering how acceptable or non-acceptable this looks like.

Here's a compiled game i used for the test:
https://www.dropbox.com/scl/fi/r52c6zy1odiabeuwnautu/walk-problem-test.zip?rlkey=3e9yfgeze8dujeeb1n4ov6d3u&dl=0
I scripted this game to make a walk between very particular coordinates that illustrate this problem case: this is done by pressing Space button.
But in theory it may be possible to have similar effect when walking around the room for the long distances.

Of course I may be overthinking this too...

Idk if this matches the topic, but there's a AGS game on Steam which is not in DB. It's commercial though, with no demo.
Title is "Castle Agony":
https://store.steampowered.com/app/827830/Castle_Agony/

Found its GiP thread:
https://www.adventuregamestudio.co.uk/forums/ags-games-in-production/agony-a-working-title/

@Baguettator
I used your code in a new game, and it works correctly. You may try it yourself, if you would just create a new test game from a random template.

Is this the real code you are using? Is this string variable changed anywhere else in script?

I think it's best to deal with cases like this in the tech help forums first, to let others look into your script and make sure it's not a scripting mistake.

I don't want to be accused of digging up this thread, what seems to be frowned upon on this forum but is it definitively impossible to fix Maniac Mansion Deluxe AGSflashlight.dll on Mac without rebuilding ?

Please elaborate, fix how?

AGSflashlight.dll itself cannot be used as is on Mac, because that's a Windows dynamic library, so it won't work ever without Windows emulation (like a virtual machine).

Therefore, the solution is to either:
- build a Mac library (*.dylib) with the same behavior
- build an engine with this plugin built-in.

Would this work better?

I'm sorry for delayed response; yes, I think this might work better.

I just tested this, and the Option text is correctly displayed in similar case, when the single option starts automatically. Are you sure it had Say checkbox ticked?

Your second dialog has only 1 option. AGS automatically runs the single option if there's no others.

Maybe it skips the "Option text" with "Say" checkbox? In that case that's probably a mistake in the engine...

You may workaround that by putting player's line as a first line in script.

In my dialog script I have goto-dialog X function which is only working correctly if I have "ShowTextParser" set to true. For some reason when I set this to false, the opening "Option text" for the new dialog branch is ignored and it launces straight into the script.

"goto-dialog" command is supposed to switch to another Dialog, which in turn should
- run @S script section
- after this script finishes with "return" - display available options.

"Option text" is not supposed to play right after "goto-dialog", because no option is selected yet in the new dialog.

I don't know how "ShowTextParser" may be changing anything in this. I did a quick test, and it works same regardless of whether the parser is enabled or not.

I think this is not an option, but a Text parser's input field.

Do you happen to have a "ShowTextParser" option enabled in the Dialog's properties?

Do you have any options in your Dialog that are there but do not have a filled title?

If not, then please give more details, how exactly did you make your option box (do you use default dialog options behavior, or custom options rendering), and also, how is the "empty row" gets highlighted if it's empty? (post a screenshot, perhaps)

In the sense of screen transitions, I always had a feeling that if it was possible to screenshot the room without the mouse cursor, ... If it was possible to screenshot without GUIs too it would be perfect

This was an old feature suggestion for idk how many years, to pass which screen layers to draw in screenshot function.

Since 3.6.1 there are no more game logic updates in the draw routine, afaik, which means it may be safe to call it anytime, passing some "draw on target" and "draw which layers" parameters.

CW, i don't know if this is considered related to the engine. But there is a bug in the Thumbleweed template that comes with AGS, to my knowledge it has not been fixed yet No updates in the Thumbleweed template thread.

This is not related to the engine, but related to the AGS distribution.

I do not know Thumbleweed template well enough to address this myself. You need to post the bug reports in its forum thread to make its author(s) aware.
Alternatively you may post in its repository here: https://github.com/dkrey/ags_tumbleweed/issues

This problem was fixed in the latest 3.6.0 patch.

For properly remaking FMV games in AGS, things may be easier if its video playback support was upgraded
https://www.adventuregamestudio.co.uk/forums/engine-development/feature-request-videos-non-blocking-playback-with-guis/

Today it's possible to use one of the existing video plugins, like this one:
https://www.adventuregamestudio.co.uk/forums/modules-plugins-tools/plugin-spritevideo-v0-9-3-sprite-and-video-render-based-on-direct3d-plugin/
(except it does not support audio)

[1. The window title]

1. The window title is assigned a unicode string in 3.6.0, this is done unconditionally now. Therefore, if a game title is saved in ANSI and contains non-latin letters, it will display as gibberish.

I think it's possible to fix in windows version of the engine, because windows API provides methods for both unicode and ANSI string parameters. But:
* this will work only on Windows, because other systems (linux etc) don't know how to display ANSI.
* this will work only on Windows systems which have "language for non-Unicode applications" set to Hebrew, or possibly ones which default language uses same ANSI charset as Hebrew.
On all the other systems this text will still display wrong.

2. The winsetup issue is because the window title is taken from the config file ("titletext" option), which is generated having ANSI encoding by the editor. This is something that I missed when was adding Unicode support to the Editor, assuming that the config file does not store human-readable text.

This should be fixed, and config file likely has to always be saved in utf-8. The engine may take care of it regardless what encoding the game requires.

3. The save folder name. Since some time the engine forces the save folder name to have only chars in certain code range, I think this is 32 - 127, with exceptions for punctuation signs. If there's any chars outside of that range, they are replaced by underscores '_'. This is done for compatibility between various systems. So, at the moment, it seems like you cannot have save folders named in Hebrew.