We need to call `video_refresh()` exactly once every time `retro_run()`
is called as per the libretro docs. These return statements were
preventing that from happening.
Since the libretro frontend can do whatever to the OpenGL state between
frames, we can't make any assumptions about the state at the beginning
of a frame.
Now it actually stops the audio instead of doing nothing.
Also, calling `Audio.bgm_stop` was causing a crash in Emscripten due to
an exception being thrown internally in OpenAL Soft and C++ exceptions
being disabled when targeting Emscripten. Shouldn't happen anymore.
This way Meson will automatically keep the Git hash updated as you make
new Git commits, rather than forcing you to reconfigure the build again
every time you make a new commit to keep the commit hash updated.
This allows more flexibility when loading games in libretro builds,
since we can now load games either from a directory or from a ZIP or 7Z
archive. Also, the path cache is now active for all filesystem calls
made from inside Ruby.
I've made it so that `Graphics.update` pauses the Ruby VM and returns to
the libretro frontend. Once the libretro frontend calls `retro_run()`
again, the Ruby VM resumes. This allows the libretro frontend to control
the rendering loop.
To stop Ruby's garbage collector from freeing Ruby `VALUE`s while we're
in the middle of using them in libretro builds, we need to make sure all
the `VALUE`s we use are on the sandbox's stack.
Also, to allow Ruby to recognize `VALUE`s on the sandbox's stack on
big-endian targets, I've changed the serialization of `VALUE`s. Before,
any `VALUE`s returned by a sandbox function were always converted to the
target's endian, and any `VALUE`s passed to sandbox functions as
argument were then converted back to WebAssembly's endianness,
little-endian. Now, `VALUE`s are always little-endian; they are no
longer converted to the target's endianness. That should be fine since
`VALUE`s are supposed to be opaque values.
This executor has the advantage of being able to work correctly when
there are Ruby stack frames underneath C/C++ stack frames in the stack.
Still need to implement handling Ruby fibers.
We can't have them as normal functions because reentrant calls into the
Ruby API don't work if you do that, i.e. calling into the Ruby API and
that calls mkxp-z's bindings and that calls back into the Ruby API.
Apparently `environ` is some kind of reserved word in MSYS2's build
environment, which caused hard-to-understand linking errors on Windows
due to one of the functions in wasi.cpp having an argument named
`environ`. I've changed the name of the offending argument to `env`.
I've also added `extern "C"` to all exported functions to make sure
something like this doesn't happen again - the compiler should now
refuse to compile the code if there are function signature mismatches in
exported functions.
