This field needs to be initialized when `struct frame` is constructed,
or its value may be random.
I also changed the type of `stack_index` to `wasm_size_t` so that it's
the same size on every platform.
This commit adds `sb()->create_object()`, `sb()->get_object()`,
`sb()->check_object_type()` and `sb()->destroy_object()` in libretro
builds to keep track of all C++ objects allocated by the bindings in
libretro builds. This has some benefits:
* Any C++ objects allocated by the bindings that are still alive when
the game terminates can now be deallocated instead of being leaked
like before.
* We now keep track of the types of all objects allocated by the
bindings, so we will be able to detect when the bindings attempt to
access objects of mismatching type.
* Keeping track of all allocated objects is required to implement
libretro save states.
* Objects are now kept track of using numeric keys whose sizes are the
same on every platform rather than pointers, which helps with making
save states portable across platforms.
In big-endian libretro builds, the WebAssembly memory is reversed, so no
byte-swapping is required to read from/write to WebAssembly memory
(which is little-endian).
However, that means the ways to get and set values in WebAssembly memory
are endianness-dependent, so I've added the correct such ways for
big-endian platforms.
The binding coroutines in libretro builds are constructed on the VM
stack, so reallocating the VM memory would corrupt the memory of any
currently existing coroutines.
I've changed it so that the coroutines are no longer constructed on the
VM stack so that they're unaffected by VM memory reallocations, and
added a "slot" mechanism for storing variables on the VM stack. (Any
Ruby `VALUE`s used by a coroutine have to be stored on the VM stack so
that the Ruby garbage collector doesn't free them while they're being
used, which is why the slot mechanism is necessary.)
Before, if the game tried to create a save file, missing parent
directories would always be created because they could possibly exist
only in the game directory and not in the save directory, and we
wouldn't know due to the union mounting of the save and game
directories. But this is inconsistent with the behaviour of file
creation, where it should fail if parent directories don't exist.
The behaviour has been changed to only create parent directories if the
parent directories already exist. I know that sounds strange, but if the
parent directories exist, it could be that they only exist in the game
directory but not the save directory due to the union mounting, so we
need to create the parent directories, which will be created in the save
directory due to it being set as the write directory in PhysFS.
Files are written to the libretro save directory, which is mounted at
/save in PhysFS. All filesystem calls made from Ruby in libretro builds
are routed through PhysFS, so the game can just use any ordinary
filesystem function provided by Ruby to interact with /save.
It's also union mounted on top of the game directory (located at /game
in PhysFS) so that games that write their save files to the current
working directory will have their save files saved to the libretro save
directory instead of the game directory.
For security and portability reasons, nothing outside of the libretro
save directory can be written to, and nothing outside of the libretro
save directory, the libretro game directory and the various embedded
files used by the runtime can be read from.
