[WIP] AGS 4.0: rewrite ccInstance into non-forking ScriptExecutor

[ivan-mogilko]

This is an experiment in a WIP stage currently.

Purpose:

• reorganize ccInstance class, separate "runtime script data" and "script execution";
• make it work without "forks", which are the copies of ccInstance, required to run "repeatedly_execute_always" while another script is suspended;
• as a consequence, in theory support any number of nested script calls made through the nested engine API calls, i.e. interleaved engine -> script -> engine -> script -> etc, which may be wanted for delegates/function pointers to work (see discussion in Let's implement delegates, as a callback and function pointer mechanism #1409).

What is done

1. The former organization ccScript - ccInstance is expanded into: ccScript - RuntimeScript - ScriptExecutor, where
   • ccScript is a loaded script data;
   • RuntimeScript is a script prepared for execution, with fixups and imports resolved, and linked with other scripts;
   • ScriptExecutor is a object that executes RuntimeScripts.
2. Engine no longer keeps ccScripts, only use them for creating RuntimeScripts.
3. RuntimeScripts don't make any "forks", there's strictly 1 per each script, and no need for more.
4. There's a single ScriptExecutor object, which tracks a callstack of RuntimeScripts passed into it, capable of starting nested script runs while there's another/other script execution suspended.

In the situation where a script would call a blocking action, such as Wait() function, for example,
previously engine would do this:

• run base ccInstance for some script event
• call Wait()
• run forked ccInstance for "repeatedly_execute_always"

after this change it will do:

• call ScriptExecutor::Run for some script event
• call Wait()
• call ScriptExecutor::Run for "repeatedly_execute_always"
• ScriptExecutor should correctly handle Run calls while there's a callstack of previously suspended scripts, and resume those after nested calls are done.

[ivan-mogilko]

I think we can push these changes further, and introduce a "Script Thread" class. The "Script Thread" will contain its own data stack and call stack, leaving only registers in the ScriptExecutor. ScriptExecutor will be told to run this or that script on a specific "script thread".

Then there will be 2 default "threads": the "main" one, and a "non-blocking" one to run "rep-exec-always" on. This will nicely mimic the previous behavior.

But the "script thread" objects may become more useful somewhen in the future if we try to implement coroutines in AGS.

[ericoporto]

I see there are changes to the script compiler, does this change requires rebuild of the auto test game with it or should be able to run the previously built ags4 auto test game ?

[ivan-mogilko]

I see there are changes to the script compiler, does this change requires rebuild of the auto test game with it or should be able to run the previously built ags4 auto test game ?

No, there are no changes to compiler itself, there are only corrections to data types in ccScript.
I've been testing this with a game compiled by regular ags4 version.

I did not have time earlier, but I will check out what happens when this runs a test game.