This isn't to fix any bug I've experienced on any platform thus far, but
to avoid problems showing up in the future, since the libretro API docs
say you should unbind everything every frame.
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.
It seems getting performance callbacks also doesn't work except in the
specific call to `retro_set_environment` that occurs before the core is
initialized, so this seems easier than handling only the logging
callback specially.
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.
