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.
This adds a new driver for audio in libretro builds for devices with
multithreading support that defers audio rendering to a worker thread
provided by the libretro frontend.
The threaded driver has the advantage that video lag will not also cause
the audio to lag, which is very noticeable since it manifests in the
form of audio crackling when it happens.
OpenAL Soft 1.24 introduces a lot of code that doesn't work well with
the PlayStation 3 homebrew toolchain, and also the old version of the
Wii U homebrew toolchain currently used by the libretro buildbot.
Instead of maintaining a bunch of patches to get 1.24 to work on these
toolchains, I think it'd be easier to just use 1.23.
The Vita builds of RetroArch and some libretro cores use these two
flags, supposedly to fix relocation-related bugs.
(cherry picked from commit 3c43cd5747b19bd4d9c0202fec1a68677ddbd5af)
I'd already removed the SDL static libraries from libretro builds for
portability, but kept the headers to make it easier to port the codebase
to libretro. Eventually it was time to stop using the SDL headers as a
crutch.
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.
I was planning on using PortableGL as a software implementation of
OpenGL, but it's really slow (at least when compared to actual 2D
graphics software renderers). I'll have to actually add a separate
rendering backend for software rendering later instead of trying to
emulate OpenGL in software.
PortableGL supports shaders, but requires them to be compiled
ahead-of-time to C or C++.
I'll write a compiler later to translate from GLSL to this format
automatically at build time.
SDL disables OpenGL headers when building for iOS and tvOS, but that
causes our builds to fail. I'm getting conflicting answers on whether or
not OpenGL is supported on iOS and tvOS, but it's the libretro
frontend's job to care about this, not mine. Regardless, I'm gonna need
these OpenGL headers for software rendering on platforms with no OpenGL
support, so I can't tolerate the headers being disabled.
The only reason why WABT suggests this flag be used is because it
guarantees that infinite recursion will crash the program instead of
running in an infinite loop.
Honestly, who cares? It's not like either of these things are supposed
to happen, so from the viewpoint of the end user, they're basically the
same thing. I think we can afford to deviate from the WebAssembly
Specification here if it means allowing the compiler to do more
optimizations.
CMake object libraries keep building with position-independent code
enabled even when it's explicitly disabled! We do, in fact, have to
build with position-independent code disabled on some targets, such as
PlayStation Vita, since some targets support position-independent code.
CMake static libraries don't seem to forcibly enable
position-independent code, so I've converted all the object libraries
into static libraries and added the new static libraries as dependencies
in Meson.
