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.)
Any relative paths that the game tries to access in libretro builds will
now be relative to whatever is the current working directory in the Ruby
sandbox, which will also now be initialized to the game directory during
initialization. Before, all of the bindings that took paths were
hardcoded to prepend the path with the game directory.
* Fixed a bug where frames are still duped when the frontend is
fast-forwarding
* Fixed a bug where manual frame duping (without
`RETRO_ENVIRONMENT_GET_CAN_DUPE`) causes screen flickering during a
`Graphics.transition` call
Okay, the coroutine implementation of `sandbox_malloc` is clearly
broken. It would be working if Asyncify instrumented the `memory.grow`
WebAssembly instruction, but it doesn't instrument it.
This commit reverts commit 42c4ff9497 and
also increases the default VM memory allocation from 64 MiB to 96 MiB to
account for the lack of ability to increase the memory allocation at run
time. I'll find some new way to implement increasing the memory
allocation later.
According to AddressSanitizer, when `sandbox_malloc` causes the
WebAssembly memory to grow in size, every single coroutine on the
sandbox stack gets corrupted. So if `sandbox_malloc` is going to cause
the memory to grow in size, we need to yield so that there are no
coroutines on the sandbox stack while the reallocation occurs.
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.
This line is sometimes throwing an exception when the sandbox is
destroyed because the sandbox is being destroyed while it's in the
middle of yielding, and I guess it's undefined behaviour to call
`__wasm_call_dtors()` while the sandbox is yielding.
As evidenced by the try/catch block, I anticipated that
`__wasm_call_dtors()` could throw an exception. But I forgot that you
can't catch exceptions in a destructor! Let's just not call
`__wasm_call_dtors()` then. What harm can that do anyways, given that we
clean up all the memory used by the sandbox in the immediately following
lines in the destructor?
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.
I've decided to stop gambling with ways to make `-e` not crash Ruby on
startup in libretro builds (see commit
1473416a5a for context). Making Ruby load
a dummy script seems to work better.
Guys, I think I'm going insane. Every time I build the libretro Ruby
sandbox with a different version of Ruby, or even when I build Ruby at a
different path on my computer, there's some chance that the builds
produced with that version of Ruby and/or that path on my computer
result in Ruby crashing on startup in libretro builds. I've been
tweaking these command-line arguments that are passed to Ruby for a
while now, and I *think* these are the correct ones that will stop Ruby
from crashing.
