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 don't think I'll be needing SDL. Pretty sure about 100% of the
functionality of SDL that's currently being used here is either trivial
to reimplement or needs to be replaced for the libretro core to work in
the first place. For example, I already know I'm going to need to
completely replace the SDL input handling with libretro's input API.
Also, I'll need to get rid of the use of SDL threads in the audio code
later because libretro cores need to render audio synchronously with the
video rendering.
I'm including the SDL headers, though, to reduce the number of
compilation errors.
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.
I'll also add PlayStation Vita and Xbox once I figure out how.
Other than that, I think that's all the game consoles RetroArch supports
that aren't Linux-based!
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.
WebAssembly is little-endian regardless of what machine you run it on,
so the WebAssembly implementation needs to know if the machine is
big-endian or little-endian to function properly.
I don't really plan on putting out another "release tag" anytime soon,
so the hash for the current git commit is being added to the version string
to help tell the difference between one build and the other.
