Messages

Slow in what exactly? Rendering, running script, else? In which circumstances? Separate components will have separate reasons for being slow. Separate game objects will have separate reasons for being slow too (for instance, GUIs update was very unoptimized until 3.5.1).

Is it that the VM's instructions are not mapped directly to the underlying CPU instructions?

AGS script is slower than many other scripting languages, because it's compiled to generally inefficient bytecode; it emulates x86 asm, but have many repeating operations that are redundant in a scripting language. I wrote a post about this many years ago: https://www.adventuregamestudio.co.uk/forums/index.php?topic=47320.0

Additionally, the changes made to the opensourced version made it even slower, for few reasons, primarily making it run on 64-bit machines and backward compatibility.
In regards to 64-bit systems, AGS script was unfortunately designed to store real memory addresses in the bytecode, which is 32-bit, therefore current engine works around that by storing them differently, and that made it slower.
There could've been other way to resolve these problems, but we never had a chance to address these again.

In the Search, ticking "Search in topic subjects only" does not work and causes errors every time.

What happens if the dylibs are not arm64?

I believe they won't load on arm64.

Perhaps try making a version without libs for which you don't have a arm64 variant.

I assume one can't build an arm64 architecture executable, unless they are on an arm64 architecture OS, right?

Edit: Also does that mean all dylibs need to be arm64 arch?

The second is definitely true.

About the first, there may be tools that allow building for a different architecture (cross compiling), but i'm unaware what is available for mac.

I don't know all details, but first of all it's best to run in windowed mode if the game supports it, because it's easier for a system to create a window than to init a fullscreen mode for an old game.

Then there's a program known as "dgvodoo", it emulates old graphic drivers. Recently we had a conversation on Discord, and a person found this may improve running some ancient AGS games which modern engine cannot run. Maybe it can help with this game too.

Updated DragDropCommon module to 1.0.1, fixing default settings, to avoid people stumbling into a missing GUI crash if they forgot to explicitly set a drag mode.

Bit unrelated, but I've been randomly thinking about all that reflection stuff, and also this feature proposal by fernewelten, and it suddenly came to me that there may be a relatively non-complicated way of implementing a variable watch in the Editor.

Assuming the editor is running a game that it just compiled, it may have a saved table of variables from the compiler (or rather - from tokenizer - a first compilation stage). That gives a mapping between variable names and their memory offsets. Editor may keep that in memory or rather save it to a file somewhere in its workspace for the future use.

When user is running a test, and wants to know current value of a variable, Editor would pass a command into the engine, asking for a value at a certain offset in the script memory (global or function stack), and engine would just return that.

Hey, could this give some C# like serialization capabilities? (imagining once generics are a thing)

Could you give an example of what you are refering to?

Hypothetically, RTTI means reflection, and as a consequence - watching variable values. In perspective - also virtual function tables, but I am not looking so far atm.
Oh, and of course, dynamic type casting - from parent to child.

In regards to generics - no idea if that will be ever possible to implement for ags script, or if it is a suitable language for that sort of thing. But some kind of "any-type" symbol would be nice... like "any dynamic array" for instance, that could be sent into specialized api. Just imagining things.

[UPDATED in 2023]

UPDATED in 2023

Test build: https://cirrus-ci.com/task/5586565305466880
Ticket: https://github.com/adventuregamestudio/ags/pull/1923

UPDATED later in 2023

This is now fully merged into ags4 branch.



It looks like we may be few steps away from actually supporting managed pointers inside managed structs.

To clarify, since not everyone knows why they are not supported, the problem is that engine does not know real contents of the struct at runtime, and does not know which members are pointers.
Because of that it cannot deduce if something inside struct also has to be released. And if there were a managed struct with pointers, these will not get deleted, creating a so called memory leak. Basically, this may lead to program crashing with "out of memory" error, because objects to which these pointers-in-struct point never get deleted.
So we had to artificially forbid them.

The proposed solution was to introduce a so called RTTI - table containing description of all the types in the game script. This table would not only tell which types are there, but also, what members do they have, and which types these members are. Specifically for this problem this description must tell which of these members are pointers.
A related ticket: https://github.com/adventuregamestudio/ags/issues/1259


I did a small experiment for fun, generating such table along with the script data, and letting engine consult it when disposing managed structs.
https://github.com/ivan-mogilko/ags-refactoring/commits/experiment--rtti

And it works - if you create a chain of managed structs in script - it correctly deletes everything when necessary without any memory leaks.

The code above is extremely dirty though, so it will take time to prepare a polished version.

Ah, that's a shame, since the lack of this Wait() API is the cause of a lot of the issues with this module. As it stands, it's not possible to fully replicate the AGS .Say() advance-to-next-line behavior in script (there's no WaitMouse(), and you cannot reliably tell whether a WaitKey()/WaitMouseKey() ended because of a click or because it timed out, much less which particular keyboard key was pressed).

Now these are added to 3.6.0, could be already tried out if necessary:
https://www.adventuregamestudio.co.uk/forums/index.php?topic=58976.msg636637973#msg636637973

yes it works now!

Sorry about that, there was a gap in the rewrite logic for games with 'other' links.  Should work now.

Unfortunately it still does not work, it does not show 404 page anymore, but it simply opens an empty page and stays there.

There is also a problem that I didn't notice before. The inventory items interact with themselves especially if you click on it once. I can't find where to check if an inventory item is on itself so that nothing happens.

Ah right, so, you have this code above, under condition "if (DragDrop.EvtWantDrop)":

Code: ags

  else if (inv != null) 
  {
    inv.RunInteraction(eModeUseinv);
  }

so you could probably also test

Code: ags

  else if (inv != null && inv != cJesus.ActiveInventory) 
  {
    inv.RunInteraction(eModeUseinv);
  }

Amir, sorry for not responding earlier.

I don't think the repeatedly_execute_always is a "wrong" place, with that it may work all the time regardless of other things you do in rep-exec.

Looking at the big repeatedly_execute() function, my first thought is that you could place it under the "if (DragDrop.EvtWantDrop)" section, after calling all the ProcessClick/RunInteraction:

Code: ags

if (DragDrop.EvtWantDrop)
{
  cJesus.ActiveInventory = DragDropCommon._InvItem;

  if ((chara != null) || (obj != null) || (hot != hotspot[0]))
  {
   ProcessClick(mouse.x, mouse.y, eModeUseinv); 
  }  
  else if (inv != null) 
  {
    inv.RunInteraction(eModeUseinv);
  }

  cJesus.ActiveInventory = null; // <---------------------
}

But maybe you tried that already and it did not work?

[EDIT:]

I am trying to add the source project link to the downloads on Game DB page.
https://www.adventuregamestudio.co.uk/site/games/game/2553-ags-cameras-tech-demo/

I put this link into "Any other download link":
https://github.com/ivan-mogilko/ags-camdemo/archive/refs/tags/v1.0.0.zip

When I open "downloads" from the page this link is shown with some kind of "back" icon referencing link:
https://www.adventuregamestudio.co.uk/site/games/game/2553-ags-cameras-tech-demo/other/0/

But clicking on that results in 404 error.


EDIT: Someone already reported the broken link, so I maybe remove it for now.

I cannot tell without seeing full code of rep exec.

I want the selected inventory item to disappear after the interaction or dropping, both in the inventory with inventory items and outside with objects

When you say "dissapear" do you mean dissapear from cursor, or dissapear from player's inventory?

[EDIT]

Hmm, I have got one idea.

Try changing the order of tests. Test inventory item first, then everything else:

Code: ags

  if (inv != null) 
  {
    inv.RunInteraction(eModeUseinv);
  }
  else if ((chara != null) || (obj != null) || (hot != null))
  {
   ProcessClick(mouse.x, mouse.y, eModeUseinv);
  }

EDIT Also I've just realized that the hotspot test is wrong. You should not compare hot with null, because Hotspot.GetAtScreenXY always returns something.
You got to compare it with hotspot[0], which is "no hotspot"/eraser:

Code: ags

  else if ((chara != null) || (obj != null) || (hot != hotspot[0]))

Does the code ever pass under "else if (inv != null)" ? You may test that either by placing a breakpoint there or "Display" command with some message.

Good question. I tried Display command, nothing happened, the Display message didn't appear.

So, inv is always null, or condition does not work.
The question is why your script does not detect an inventory item at the place of the drop.
Maybe the detection is not correct. Or there's some extra code that prevents this to work.



I made a quick test with the existing Demo game, and added few lines in the 4th room script:

Code: ags

  else if (DragDrop.EvtWantDrop)
  {
    InventoryItem* item = InventoryItem.GetAtScreenXY(mouse.x, mouse.y); // <-------------
    if (item != null) // <-----------------------------------------------------------------------------
      Display("item under: %s",item.Name); // <-------------------------------------------------

    InvWindow* drop_to = GetInvWindowUnderObject(o_x, o_y, o_w, o_h);
    if (drop_to != null && ItemOrigin != null && drop_to != ItemOrigin)
    {
      ItemOrigin.CharacterToUse.LoseInventory(DragDropCommon._InvItem);
      drop_to.CharacterToUse.AddInventory(DragDropCommon._InvItem);
    }
  }

This displays inventory item's name under the mouse cursor every time you drop something on it.

inventory items still don't want to interact with other inventory items.

More information is needed.
Does the code ever pass under "else if (inv != null)" ? You may test that either by placing a breakpoint there or "Display" command with some message.
You are running eModeUseinv interaction. Do you have event of that type ("use inventory item on") created for your items?
What is inside these event functions, are there more conditions? Can you post an example of your script?