I’m not sure at all, I haven’t tested it, so I’m taking wild guesses:
it’s compiled from asm, C or C++, with special compilation/linking flags ensuring only the dependencies for the guest program are present.
That will NOT work for simulator versions however! The server will need to send proper binaries in this case, and the client program will need to load it.
(of course there are numerous security issues that can happen here)
The guest program can probably be hosted in flash or ram.
However, that location might need to be known in advance before compiling, unless some relocation can be done on the fly.
The same will also happen for the memory location of any static data the guest program might need.
If the host provide memory allocation utilities, new/delete can probably be used almost as normally, so no specific restriction about heap memory.
Stack memory shouldn’t be an issue either.
host and guest must have the same layout for shared memory objects, same args/return values for shared functions.
Maybe inheritance is possible, but I worry about the compiler optimizations …
Pointers to functions would be fine.
Any access to the STL/standard library/pokitto library/any kind of library is most likely prohibited.
Everything must goes from the guest/host API!
so if you want to render something on the screen, you need to have that call in your call table somewhere, or have your guest program access directly the buffer/linebuffer/whatever.
it’s excellent for an RPG which only has things like “display dialog”, “set hp to X” and that kind of commands, but it can become huge when you want guest programs to be more polyvalent !
Perf-wise it should be as fast as regular C++ programs. However the call table will be slower than the normal compilation counterpart (at the cost of an additional lookup - so if you’re doing that a lot…)
extra care must be taken into making sure the server is giving a guest program proper to the client’s version, or crash will happen.
in a nutshell:
very versatile and powerful, and quite fast.
very fast to download and load.
only limited by the API.
Lot of care are required for versions checking.
you probably can forget the debugger.
quite elaborate to configure, and require even more dispositions for making a simulator version happens.
downloading and executing code from a remote server is also a an opportunity for security issues.
Thinking about it, it might be too complicated to implement
There are other solutions as mentioned before:
Bytecode interpret style.
Much slower, but probably the most secure, and no specific things to do for the simulator version. Will probably takes a good chunk of flash to implement tho!
Could be shorter too (so less memory used for the program itself), depending on the situation.
Pine2k style.
At the price of a compilation, you’ll get a good program running at an excellent speed.
If the API doesn’t match, it just won’t compile - so many less UBs (hopefully).
Streaming style.
The server fully controls the tiles/sprites/layers/etc with a generic protocol.
It’s basically like a smart remote desktop connection.
Susceptible to lag, and bandwidth might become an issue.
(disposition can be taken to limit the effects of lag - like being able to give animation curves and so).
But limitless otherwise!
this is what rooms is using.
No rules of the bomberman implemented in it are known by the client. I did have to add more sprites and some “remote instructions” to adapt the UI and camera too.
I think we do not have an interpreter in Pokitto, except MicroPython and it is too big for this purpose.
I also think that the project will be too laborous if it includes a new bytecode interpreter
C++ and Pine2k seem to be the most promising solutions for the quest programs.
I would be tempted to use Pine2k. Maybe we could cache the compiled Pine2k programs to SD so it would not take time to compile every time the minigame is launched.
iirc pine2k scripts are compiled only one time within the same launch, so that’s already -if true- the case! however it’s always best to compile them at least once per launch (and not per installation), to avoid weird behaviors in case the client gets updated in between. Also the compiler is using a significant amount of RAM by itself, so scripts might have to be kept short in any case.
also, I’m not sure if pine2k had a simulator version I think @FManga (if you’re around that’d help!) was showing some x64 assembly generated out of it, but I’m not sure if it ended up in such a version.
Also, remember that if the bytecode interpreter takes some flash space, a pine2k compiler will also take some flash space, possibly much more!
so far as I see, only the bytecode interpreter is a clean solution running on all platforms, but as you said, it brings in a cost - and you need to design some sort of language or use a transpiler anyway to make it usable (I doubt people would love to make some assemblish coding for their games )
All solutions have issues and advantages, and all have moderate to high costs of implementation and maintenance.
To be honest, I’d go with another way:
First, make a few simple minigames in C++ (or C ish C++) by using a very simple, scoped API (like one in pine2k style) for such games
Make sure they work properly, playtest them, etc.
Then decide from there if it’s even worth it to introduce an interpreter or pine2k. It’ll be only worth adding such a feature if we run out of flash memory after all!
Actually, instead of caching, we could precompile the minigames with each client version and distribute the binaries with the client. Then we could leave the pine2k compiler out of rom.
We need dynamic loading of minigame binaries so we can have tens of minigames in “Pokitto Party”
Debugging is a problem thought. Especially for MP games it is quite essential to be able to debug on PC. The emulator do not currently support MP at all.
in this case, the simulator version could probably just embed them inside the executable and load them as function pointer(s) directly, tho the minigame API would stay the same.
So most of the debugging related to the games themselves can be done there (and with the right sanitizer that’d remove a lot of issues not related to loading the executable part iself), with the right addresses/symbols/everything available to the normally configured debugger.
We can also use the good old dynamic loading on simulator to have a close environment of what happens on the HW!
In any case, the code loading issue should be taken as a separate beast by itself. If it works, it’d be very nice to have that as an advanced library!
As soon as we can validate a tiny api of 3 basic calls or something on HW, we can work on a few prototype games to help flesh out the whole thing. then we can maybe launch a jam to populate this api. we also have to think about how to load custom graphics in a simple way with such an API, and the server (or host) part is a beast in itself exciting tho
I think 
)
