Messages

OK I'll have to dig it out. you don't remember ever saying : "We can't do _________ because in AGS VM pointers for _________ are the same as pointers for ________ and the VM can't technically tell the difference"?

[share the same address space as basic pointers]

I remember CW saying that one of the obstacles of easily "managing" managed objects inside the AGS virtual machine is that they share the same address space as basic pointers. I don't remember exactly which kind of difficulties it was causing but I clearly remember that it was creating a technical glass ceiling -- because in the end everything is a pointer. So this limitation was indirectly impeding some glorious steps towards engine modernity and dynamic objects. 

This message is not to ask "what is the problem exactly" but to suggest a solution. Maybe what I'm about to write is dumb and has nothing to do with the issue, but here goes nothing. I've done that successfully in some pseudo-VM I was writing in AGS :

Split the pointers address range in two. I mean, a pair of completely artificial "fake" addresses ranges. For example :
0x0000 --> 0xFFFF = old-style pointers, nothing changed.
0x10000 --> 0x1FFFF = managed objects. You generate those exactly like you used to (values from 0x0000 to 0xFFFF), but you immediately add 0x10000 for as long as they're passed around as value from C++ function to C++ function-

With a simple binary mask you can tell which value represents which type. <= 0xFFFF = regular pointer. >=0x10000 = managed pointer.
Whenever you need to actually read/write to memory, just remove the bogus offset : For example, convert managed pointer 0x100AA to 00AA, then do whatever you would normally do (pointers arithmetic, real address in memory, etc.)

Food for thought.

Miez, thank you for publishing this. It was important and the mature thing to do.

PS: Did you ask the other artists' permission to publish their share of the project too? This is too precious to rot on some hard drive (until it fails) or scattered away until no one remembers who has the last piece.

eErio what are you waiting for? Use your coding magic to rewrite this module from the ground up in AGS 3.5 

[ambient occlusion]

You don't seem to have any ambient occlusion shading? Especially where the walls meet the ground that's essential.

I'm very excited by this game.
All the visuals and music are super tasteful yet not over-the-top, one can clearly sense the artistic sensitivity in this project. A real vibe of Monkey Island 1 -- except in VGA and with less shoehorned spoofs

[only that one "what's up?" at the very beginning of a conversation with an NPC]

(About voicing)

I've been giving a lot of thought to this.
Two facts :
- Silent games are more and more out of place in nowaday's "all-talkie" game space.
- amateur games can't afford to have fully voiced games.

I've been thinking of doing this :
- Voicing only introductory sentences. For example, only that one "what's up?" at the very beginning of a conversation with an NPC. And their very first, short greeting back.
- I would also voice non-verbal things : loud scream, *oumpf!*, sighs, etc.
- Maybe (maybe!) the whole intro if possible. that's already in the realm of wishful thinking.
- Putting a lot of effort in the sound design for other things : music, object interactions, white ambient noise, wind, etc.

Wow this was buried in the forums but this needs to stay up!

I understand everything you wrote. For argument's sake, I'd simply like to say "yeah, ok, structs still exist out there but no one uses them in modern languages except for very specific, optimization-related reasons". And in any case their syntax is not different from classes.
The removal of the star is good enough for me.

That being said, the reasons you mentioned related to the byte code are solid. Always that same glass ceiling. Damn.

Maybe AGS 4 should be 64 bits and ditch retro-compatibility.


This is from 2018 :

[imgzoom]https://www.extremetech.com/wp-content/uploads/2018/04/Modern-OS-Marketshare-640x367.png[/imgzoom]


96% of Windows installed were already 64 bits.

Of course hashmap or btree may be somewhat slower than accessing objects directly, but

Indeed, if it's not for direct access but only for disposing and such it's no big deal.

I'm mostly talking about the script language being slow. It's a bit suicidal to iterate a lot on some data in AGS, or implementing processing that does a lot of function calls.  Both the stack and data access are rather slow.
Again, it's enough for a 320x200 game, but I'm only just wondering why it's not going at the speed of light.

object references could be direct but they use a hashmap/btree

Ouch.

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

Interesting read. Thanks!

[Context:]

Context:
AGS has no problem working with high-resolution games : With hardware acceleration it can display lots of sprites and tint them, etc. The engine is also performant enough for scripting effects when you stick to built-in operations (native sprite scaling, native transparency, etc.).

But AGS becomes slower when you want to make the AGS script handle more intensive algorithms, such as iterating on large arrays of hundreds of thousands of items, or trying to perform per-pixel operations on larger sprites, or when your function calls stack exceeds a certain depth.

This is why when it comes to scripting, especially special effects, AGS is better suited for low-resolution games : 320x200 or 640x480. And that's also why advanced shaders written with the AGS scripting language are out of the question.


I sometimes ask myself why that is. What are the reasons why the AGS scripting language is not lightning fast?

Having very little knowledge of the engine's code, I can't seem to come up with a reason :
- It uses SDL, which is very close to the hardware. If not the fastest possible option, it's pretty close.
- It's written in C/C++
- The virtual machine is running pre-compiled code, literally just byte code.

So, what is slow in all this? Is it that the VM's instructions are not mapped directly to the underlying CPU instructions? Is it that the engine uses simple data structures with a lot of overhead and lookups? Etc.

Reviving this, september 2021.

- What is the current status of AGS games running on ScummVM?
- Who is involved from the AGS forums?
- What is the best place to talk about it?
- What are the current limitations? (theoretical ones -- Not talking about performance and such)

Spoiler

ScummVM as the de facto AGS engine has a tremendous potential because... It is signed and downloadable from stores. Lol, ScummVM on iOS/MacOS expreriences the same roadblock as many other open source apps on Mac recently : it requires to be built with XCode and ...the critical features of a Mac Developer account (related to signing) is no longer free.

[close]

[I'm not allowed to change the value?]

They are marked as "Build Action = Embedded Resources"

That's the thing I forgot existed.


I'm not allowed to change the value?
I can see the Properties of each and every icon, but it appears in dark gray : I cannot modify the value...
I'm using Visual Studio Professional 2019.

["Resources" tab]

I see that there seems to be some Resources somehow connected to AGS.Editor.Resources.ResourceManager but I fail to see how to view/edit them? When I open the "Resources" tab of the AGSEditor project's properties (or simply when I open Resources.resx) I don't see any of the icons.

[ResourceManager.GetIcon crashes.]

I want to add a new sort of "Component" in the AGS project tree.

- I duplicated "ScriptsComponent" and named it "FooComponent".
- I replaced the word Script/script/Scripts everywhere relevant.
- I did "AddComponent" in ApplicationController.cs
- Finally, I duplicated "scripts.ico" and "script.ico" in the Resources folder and named the new files "foos.ico" and "foo.ico".
- I added those files to the Resources folder in the project ("Add existing item").

Everything compiles, but when the Editor starts, ResourceManager.GetIcon crashes. It says that "System.ArgumentException: 'Resource 'foo.ico' cannot be found in class 'AGS.Editor.Resources.ResourceManager'.'
.

Again, I did everything like ScriptsComponent does it, except with "Foo" in place of "Script".

So, my question : Do new resources (icons) need to be added explicitly to some sort of Resources manifest file or some list that I failed to locate?
Why are the new icons not found? Not found in what? (in the file system? In some list?)

[Does f become null? Does it have a value that will make the game crash? Etc.]

The end of your message is overthinking it. I don't really need to reposition the file. I just want to know "what would happen".
You wrote that File* is never saved. So, what happens to the variable f in this situation if the game gets saved then restored in-between some of the repeatedly_execute:

Code: ags

File* f; //global variable

void game_start() {
    f = File.Open("file.txt", eFileRead);
}

void repeatedly_execute() {
    if(!f.EOF) {
      String s = f.ReadRawLineBack();
    }
}

Does f become null? Does it have a value that will make the game crash? Etc.

"Go try it yourself, you lazy bum" is an accepted answer.


Also, you wrote that the game cannot quit in the middle of a script.
So does that mean that the game would hang (or at least refuse to quit) if I clicked Windows' "close" cross while this is running :

Code: ags

noloopcheck void Hang()
{
   while(true) {
      int i; //arbitrary no-op
   }
}

void repeatedly_execute_always()
{
    Hang();
}

Hello,
I don't have a specific situation on mind, I'm asking about general best practice.

Let's say you have this :

Code: ags

    File* f = File.Open("file.txt", eFileRead);
    while (!f.EOF) {
      String s = f.ReadRawLineBack();
      //EVENT HAPPENS HERE
    }
    f.Close();

Notice the line "EVENT HAPPENS HERE". I'm talking about random events that almost never happen but could happen.

Two scenarios :
a) On that line, this game gets saved (e.g. through "SaveGameSlot" in another script) and then instantly quits (the player closed the game in Windows).
b) On that line, another game gets restored (e.g. through "RestoreGameSlot" in another script). As a mental exercise we imagine that we restore a previous occurrence of scenario "a".

Question:
If "a" just happened, then do I just have to accept that the file is not entirely loaded into the game's VM, and deal with it next time it gets loaded?

If "b" just happened, then
1) Is f in an undefined state? I guess I can't just continue reading from it.
2) What should I do? Just scrap it and have a mechanism to restart reading the file from the top?

Ok then, thank you. I understand the ins and outs of AGS inner workings, but I'm really interested in a practical solution.

What I understand by "casting to child type is not possible unless you do it yourself" is "you must do it through something similar to monkey's example: create a new instance of the child type and manually 'recreate' it by starting off the parent's data and passing child-specific data". I understand.