Messages

About the "by reference or "by value" issue:

How about submitting a pointer to the function and overlays would be created by reference, whereas supplying a sprite slot would result in creating a copy.

Which pointer? If you mean sprite's, there's no Sprite type in AGS to pass a pointer for, only DynamicSprite, but that would limit this to dynamic sprites only. Unless we create Sprite type to address all the sprites.
In general i think such approach would be confusing to people, and inconsistent with the rest of the script commands, where assigning a sprite slot does not create a copy.

I think image zoom does not work again. When I click x2, x3 etc, the image simply dissapears.

Having overlays in rooms was simple enough to make, and it opens many possibilities, so perhaps will be added to 3.6.0, if testing is successful.

I think I won't plan p1 for 3.6.0, because there are more things to consider there (like the dynamic sprite handling that i mentioned). And since it's already in Beta, so perhaps I'm already pushing it a bit too far with new features.

Well, is someone wants to try out the experimental build, here's room overlays support:
https://cirrus-ci.com/task/6659508301725696

Room overlays are created using new pair of functions:

Code: ags

  /// Creates an overlay that displays a sprite inside the room.
  import static Overlay* CreateRoomGraphical(int x, int y, int slot, bool transparent);
  /// Creates an overlay that displays some text inside the room.
  import static Overlay* CreateRoomTextual(int x, int y, int width, FontType, int colour, const string text, ...);

They are same overlays, but drawn and sorted in the room space using their ZOrder property. Unlike characters and objects they don't automatically change their order when moving along Y axis, so if you want them to do that, you have to write something like this in script:

Code: ags

function room_RepExec()
{
	if (roomover)
	{
		roomover.ZOrder = roomover.Y + roomover.Height;
	}
}

Maybe something for future AGS releases to take into account vehicle acceleration switching gears, etc. It's just an image flying over the screen lookin' a bit unfinished atm. 
I guess i'll have to wait for it then, maybe i'll give it a go later, perhaps you guys could use some feedback from the "average user", who knows.

Well, you don't really need future AGS releases to implement acceleration or switching gears, this all may be done in script. You also don't need Character.setwalkspeed, you may always set x,y position yourself, and then implement velocity and acceleration as variables that you change in script.

[The direct 3D plugin by AJA]

and the The direct 3D plugin by AJA, i think i've red somewhere that you should be able to rotate with it, i know it's only available for PC, and i have no plan to do a "multiplattform" release in the future, yet anyway, so i would have liked to try it out, and see what it can do. I mean ofc i could try and rotate the wheel in animation instead, but it's not gonna look pretty. It's none aliased pixelart after all and it's obvious to the eye in Thimbleweed Park forexample that it's a sprite that is rotated with some 3d (probably) trickery or such. I will try what you've wrote out of course, but it sounds like it's not what i'm looking for since the antialias that is most likely is going to happen will ruin the pixelart, Thanks for your reply as always!

This is true, rotating the sprites with dynamic sprites will always be pixelated. D3D plugin should indeed solve this problem.
We also have an experimental version of AGS which supports rotating objects in 3D, but it's a wip version that changes often, and not "official" yet, so idk if i should recommend it.

I've downloaded modules and just started crying, pretty much. I make zero sense out of them.

Which modules, is this also related to sprite rotation?

In regards to the sprite rotation.

1. Don't use standalone image files unless absolutely necessary. The examples in the manual are often horrible.
Instead, import as a regular sprite instead and create dynamic sprite from its number.

Code: ags

DynamicSprite* sprite = DynamicSprite.CreateFromExistingSprite(WHEEL_SPRITE_NUMBER);

2. Don't draw on room's background, unless absolutely necessary. Drawing on room will require you to also repaint background itself whenever the sprite must change.
Instead create a room object and assign dynamic sprite to it:

Code: ags

oWheel.Graphic = sprite.Graphic;

3. Don't delete the sprite until the object is no longer needed, because object is using it to display itself. You need to make a room variable that stores your dynamic sprite for the whole duration. You may delete the sprite when player leaves the room.

Code: ags

// room script
DynamicSprite* wheelSprite;

function Room_BeforeFadeIn()
{
    wheelSprite = DynamicSprite.CreateFromExistingSprite(WHEEL_SPRITE_NUMBER);
    wheelSprite.Rotate(90);
    oWheel.Graphic = wheelSprite.Graphic;
}

function Room_OnLeave()
{
    wheelSprite = null; // this will also delete the sprite if that's the only variable that references it
}

4. Also, when you need to rotate the sprite again, recreate it instead of changing previous dynamic sprite. This is because each rotation will degrade the image quality. For good results create a new dynamic sprite from the same original slot, rotate it and assign to the same variable and then to the object again.

[technically]

There have been some improvement to Overlays in 3.6.0, and generally improvement to perfomance of GUI and overlays since 3.5.1, I've been also looking for other opportunities to make Overlays more useful in the long run at a low effort cost (since 3.6.0 is in Beta, I would not want to do any serious code rewrite in this version). There are couple of ideas that technically should not be difficult to implement, but would require some good solution script-wise. Even if these won't get into 3.6.0, this still would be interesting to discuss.

These ideas are:
1) Overlays without sprite copy, but with a sprite reference;
2) Room Overlays.



1. Overlays with a sprite reference

Right now Overlays work with a full sprite copy. I guess this may be because they were first created as textual objects, and later expanded to also have sprite on them.
This makes it easier to create textual overlays, as you just have to pass a string into Overlay.CreateTextual. This also makes it somewhat easier to create graphical ones with Dynamic Sprites, as you don't have to keep that sprite anymore: as soon as overlay is created - it has a sprite's copy, and dynamic sprite may be disposed. Unlike that, if you're using dynamic sprites as object graphic or view frame, you must keep that sprite in a global variable at all times, otherwise the object will loose its graphic (in the past it also crashed the game, but not anymore: now it simply resets it to sprite 0, for safety).

Unfortunately, such approach backfires when you are reusing the sprite on several objects, in other words - either a) displaying same sprite often, and especially if b) using multiple overlays to display a larger numbers of identical images. Overlay itself is a simple struct, but each time when created it also copies the sprite. That makes its creation slower, and increases the overall memory use. In fact, it also increases the disk space needed for a save, as all overlays must write their bitmaps into the save file; which is quite silly if you used a regular sprite from the game resources to create them.
This is even more sad as overlays today are the only object in AGS that may be created at runtime in script. On one hand you may use it to generate graphic scenes on the fly, on another - it is not as optimized as it could be.

There's another consideration here. As you might know, AGS uses "sprite cache", that is - it caches often used sprites in memory to keep them ready and not load/allocate over and over again. Unfortunately, it does not do the same to textures when running Direct3D or OpenGL renderers. That is a general issue, and rather annoying one, as it makes these renderers actually somewhat slower* and more memory consuming than they could be (*slower in one thing, but thankfully they still balance this with being faster in others). I think that one of the future improvements (and quite overdue) is to also cache the textures prepared for particular sprites. If that's done, then whenever you assign a sprite repeatedly, not just the sprite won't be reloaded, but also the texture won't be recreated but taken from the cache instead and shared between multiple objects.

But even if that's done, with overlays things would remain the same, so long as it's function is based on a sprite copy.

So, what is that script problem in this situation? Technically there's little issue: just don't make a image copy and add a sprite reference instead.
But if this is done, that would change the known overlay's behavior, where user may paste a dynamic sprite over it, and discard the sprite object. Instead they would have to make global variables for these sprites and keep a record on them, deleting these when no longer necessary, etc.
Perhaps this is also a problem with the dynamic sprite management in AGS, as their references are not contained in some storage where they will be "safe" from occasional loss, but must be referenced by a script variable.

EDIT: Another difference between having a sprite's copy and a reference is that you may continue editing same sprite after assigning it to a game object. If an object has sprite's copy - then it won't receive further changes. If it has a reference - then it will be automatically updated as soon as you finish editing the sprite (call to DrawingSurface.Release()). /EDIT

What could be a solution here script-wise, if we would like to allow Overlays with a sprite reference instead of a copy? Should there be a new function, that explicitly sais that it's not copying the sprite? Or, on contrary, a function that sais that it makes a copy, while CreateGraphical would make a reference? Are there any alternate ideas maybe?

In regards to dynamic sprites, that may be a separate question (or is it?), but one idea is to treat their assignment to an object as a proper counted reference, thus making them not automatically disposed while their number is assigned to at least one game object.



2. Room Overlays

IMHO this is a interesting idea. Overlays are unlimited (since 3.6.0), easy to make in script, but they are always on top of the room. They received ZOrder property in 3.6.0, so now may be freely sorted among GUI.
In my opinion, it's technically not hard to allow have them inside the room, where they sorted among the room elements (objects, characters and walk-behinds). This opens very good opportunities for setting up temporary visual effects inside the room, as well as generate room scenes in script. Especially since other objects are fixed, and cannot be created or deleted at runtime right now (that would require significant change to how AGS is designed, and is a separate big topic).

But the question that I have is again, how to organize this in script to make convenient? Having a boolean argument in CreateGraphical / CreateTextual is simple, but may be annoying. It may be an enum, which means "game layer" or something (like, eRoomLayer, eGUILayer). Alternatively, these might be separate pair of functions, e.g. Overlay.CreateRoomTextual and Overlay.CreateRoomGraphical.

What do you think?

And is there a particular thread discussing the new possibilities with overlays?

There's not that much to mention, this is a relevant part of the change list (you may find it in the 3.6.0 release thread):

- Added Overlay.Width and Height properties, that let you freely scale existing Overlay.
- Added readonly Overlay.GraphicWidth and GraphicHeight properties that let read original overlay's graphic size (for textual overlays too).
- Added Overlay.Transparency property.
- Added Overlay.ZOrder property that lets you sort Overlays on screen among themselves and GUI.

EDIT: oh right, and also quite important

- Removed Overlay limit.

So basically overlays at the moment are the only graphical object in game that a) is not limited b) may be created and deleted in script.

Overlays happened to be the most useful kind of object in todays AGS when you need a large number of moving and transformed (scaled etc) sprites on screen.
* overlays are designed unlimited (limited only by the program memory)
* they are rendered as a texture and thus accelerated by the graphics card (if you run with Direct3D / OpenGL render).
* it's a tiny structure without any superfluous properties that may screw logic up if not taken care of.

Before 3.6.0 room objects and characters could be more performant, as overlays did not support scaling for some reason, but since 3.6.0 beta Overlays may be scaled too
(https://www.adventuregamestudio.co.uk/forums/index.php?topic=59842.msg636645302#msg636645302)

PS. There's currently a serious issue remaining with overlays that they don't share a sprite reference, but make a bitmap copy; i believe this should be taken care of in the future.

About template, I mean like evolving from the issue you describe, it's the last proposition you present in your list, on the top post.

Hmm, if you are refering to the paragraphs starting with "An example of a very straightforward solution for type safety could be helper function template, where implementations would deduce a type and pass it further to actual registration."
That was merely a suggestion for registration helpers. It was supposed to be on top of the actual system, and its only purpose is type safety, not changing anything in how it works.

About fuzzie port, you meant the interface here: https://github.com/adventuregamestudio/scummvm/blob/ags/engines/ags/scripting/character.cpp#L2130-L2142 ?

We have a similar interface, but the difference is that she also passes the function type along. In her variant this type is defined as a string "i", "iii" and so on.
But looking at the how this solution works again now, she does not have a switch, which I thought about for some reason. In fact, she came to an opposite variant, where the api functions actually are like our "wrapper" functions. E.g. like this.

This is an alternate approach, which I forgot to mention in the ticket for some reason. It's to instead have this kind of function type exposed to plugin API, and make plugins work with it instead of calling functions of potentially unknown prototype.

The consequence of such approach is:
* any previously existing plugins which use script functions will no longer work;
* plugins will likely have to pack parameters in an array in order to pass them into this function (extra work for them).
* a big "cleanup" work which would replace calls to "real functions" in wrappers with a working code itself, similar to how it's done in fuzzie's port.
I might add this information into the ticket later.

https://github.com/adventuregamestudio/ags/issues/1223

I still doesn't understand which type of solution for that you would find acceptable. Like the template approach you mention, would it be accepted?

I can't tell which "template approach" are you refering to?
Personally I wanted to try the switch method described in the ticket, similar to what fuzzie did in her scummvm port. It may be not hard to make a minimal version with only few registered functions and test for correctness and any perfomance changes.
From the function-registration side this approach requires functions to register along with the "type description" that notes the number and types of parameters, and type of return value. This description may then even be made available through the plugin interface.

Or are you looking into the reverse, like the Lua FFI interface (https://luajit.org/ext_ffi.html), which would register C functions to the AGS Script interface, and then it's mostly about exporting the AGS Engine API as C functions.

I don't know what "FFI" is, I would have to research that first to have any opinion. But the short term goal is to be able to easily share registered functions at least between script interpreter and plugins, because a plugin may implement any scripting language and use engine api to call the functions. Similar to how lua plugin was done in the past.

About disconnecting the Script Runner, if it was less entrenched in the engine, this would make two things:

• ease with improving it
• reducing the barrier to connect other script runners (e.g.: Lua Jit)

As a note, this task will probably have to be completed in order to make engine not connected too hard to current interpreter:
https://github.com/adventuregamestudio/ags/issues/1223

as explained in the ticket itself, where it sais

The way these "translator" functions are registered, and because they are using internal engine's types not meant for anything else, prevents from sharing same registration with other potential users.

I would not trust the compiler as much. I don't think the checks are that burdensome - they only happen at the frontier in the API, which is not what I meant.

What fernewelten is refering to, probably, are checks that are done by the script interpreter during certain bytecode operations. Like - stack operations. They happen all the time, for every little move on the stack (I know that some were disabled in the past, but some may remain).

As for trusting or not the compiler, frankly in all these years there have been a minimal amount of errors found by these checks, maybe one in several years. fernewelten's proposal to have separate "production" interpreter, and "debugger" makes sense, in my opinion. (There has been a ticket regarding this, although it's more like a note, not a full plan: https://github.com/adventuregamestudio/ags/issues/843)



Then, there are things introduced during earlier rewrite, when trying to handle 64-bit problem, and backward compatibility, that may be bad, like virtual method calls in dynamic object wrappers. Where the old interpreter would simply access a memory pointer and read and write in a buffer, the new interpreter will dereference 2-4 pointers and maybe make a virtual method call.
In other operations, where old engine would do a simple pointer math (+/- a single value), the new one does more computation (e.g. see https://github.com/adventuregamestudio/ags/issues/869)
This all objectively slows things down, which may not be too much for a single operation, but will accumulate if there's alot of them, especially when working with dynamic arrays, i think. What makes things worse, some of these were probably necessary only in certain cases, but not all the time, yet affect many actions.

In any case, whether something slows things down or not, and how much, should not be guessed, it has to be measured.

Personally, I believe that it may be worth to go back to the old script interpreter and look at the system awhole, write down notes about the big picture, and search for a better solution to the problems which I and JJS were trying to solve with this rewrite. Maybe some of these problems have much better and simplier workarounds.

For the reference, there also is the earlier ScummVM AGS port done by fuzzie, from which I took some inspiration, and strangely we came to similar ideas about interpreter. My memories of it are vague now, but maybe it's worth checking out how she solved same issues in her rewrite: https://github.com/adventuregamestudio/scummvm/tree/ags



As for merging instructions, this also may be looked into in the parallel. There's an old thread about this here, but there has been no work on that. There's also a code optimizer written by rofl0r called "agsoptimize" here, from what i understand, it does not introduce new instructions, but squashes multiple into existing ones.

BTW rofl0r also has a tool that runs purely bytecode without the engine, if that's what you meant by "disconnect the AGS Script runner from AGS Engine"? it's called agssim:
https://github.com/rofl0r/agsutils/blob/master/agssim.c

On a side note, theoretically speaking AGS is capable of rendering textures in full 3D, that is, for example, it could render a sprite rotated at a given angle along non-z axis, to achieve similar effect as the water in this demo game (or race track in AGS Kart demo game).

The biggest issue is the lack of "3d pipeline" as some called it, or in human words - there's no script commands and internal functions that would let configure this at the moment.

Hey, this issue with vox packages will be fixed in the next 3.6.0 release.

Temp build may be downloaded here for a test: https://cirrus-ci.com/task/5385155433988096

[@eri0o]

@eri0o,

I am relying on sdkmanager to update/verify installation of things

May these steps be simply considered optional and skipped with a warning?
If Mehrdad had apk created earlier, does not that mean that the building itself worked? Perhaps if sdkmanager is not present, or there's another problem with it, you may simply issue a warning and try continue with building?

My guess is, there may be other potential problems there, e.g. if your script wants to install things, that requires internet connection, if I understand right. What if there's no internet connection.

Maybe it's even worth adding a user preference which tells whether perform this step, as user may want to not connect to the internet or download anything while building the game.

@Mehrdad, have you set an actual path to android sdk in the Preferences window?

Please integrate unicode last version (by CW) too.

Please note that we cannot integrate it with the official Android port yet, as unicode feature is not ready; I'm planning to work on it properly soon. We may only post a test version which merges unicode with Android, but it will not be guaranteed to be final, and should be used to create actual game releases.
Currently you may use the existing method of putting unicode in game - using the translations.

[app-mygame-release.apk]

Ok, sorry, I made a mistake. There apparently have been some older version of SDK from couple of years ago, which I thought is current one.
The directory in "...\AppData\Local\Android\Sdk" was practically empty with only 1 file inside.

I fully deleted Android Studio and SDK from my system to be certain, and resintalled again using most recent version, and double checked the new paths. Now the building is running (still waiting for result while I type this).

UPDATE: it completed successfully now, and there's app-mygame-release.apk.
Maybe a silly question, but should not it use game's name? or I missed another instruction?