I don't think we need the event thread when all we're doing is rendering
to OpenAL Soft's loopback driver. Besides, the event thread was causing
crashes in Emscripten builds.
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.
