There was a problem where we were relying on module initialization ordering. Now that modules are initialized in an arbitrary order, we can't guarantee that event will be loaded before headset.
There is a problem when a Thread stops: it destroys all of the modules
that it required. This is because we unconditionally call luax_atexit
when modules are required, and when the thread lua_State dies it takes
all of the modules with it. To fix this, lovr<Module>Init will return
whether or not initialization successfully happened, which provides us
with enough info to know if we should place the luax_atexit destructor
Platforms that want to use glfw for most of their platform code can
include "glfw.h" for common functions, in a single-file-lib fashion.
All glfw code is in this file.
Dynamically loading things was cool but is causing more pain than
pleasure because it just barely doesn't work everywhere. Instead,
find a better way to load modules. Use a data driven luaL_Reg array
to define the module mapping and luaL_register to smoosh it into
package.preload at boot time. Benefits:
- LOVR_ENABLE_<x> defines are respected and only require a single #if
- Module list is data driven and defined in one place
- It's faster (luax_preloadmodule did a global lookup every invocation)
- It works everywhere
Oh also threads were totally broken and this (mostly) fixes them.
Back out lovrHeadsetExtractRenderFn, don't let oculus_mobile.c pcall the render function, instead fit the render error saving inside renderHelper (emscripten/oculusmobile path). The render error is now saved in the environment at _lovrHeadsetRenderError. For this to work, luax now keeps track of a global variable for the current "main" environment.
This does means the render error path now works on emscripten (this has not been tested).
General changes:
- Amended the boot.lua error handling so when an error occurs in the error handler, the inner error is printed before quitting
- Silent quit instead of crash if a user implements lovr.errhand but it doesn't return a function
Oculus Mobile changes:
- The lovr.errhand screen is now correctly invoked for errors that occur inside lovr.draw. Multiple changes were needed to make this work:
- Instead of calling renderHelper, which uses lua_call (unsafe as Oculus Mobile does not call renderHelper) the oculus driver gets hold of the Lua ref and lua_pcalls itself. A new lovrHeadsetExtractRenderFn is added to make this possible.
- A mechanism is added where if the coroutine resume in boot.lua returns a value, boot.lua treats this as the string returned from luax_getstack and invokes lovr.errhand.
- Added a custom atpanic that routes through lovrThrow (since stderr gets eaten). With the draw() changes this should never be encountered, but it's good just in case. In current testing the tracebacks this prints don't seem to be right.
- Fix major bug in android_vthrow that meant % codes didn't work in lovrThrow on Android
- Nothing to do with errors, but fix getAxis("trigger")
This is used in the oculus mobile driver, allowing replacement of the (dubious) recursive-copy-from-zip code.
In order for this to work, the argument parsing must be beefed up a bit and also PhysFS must be updated to the newest master in order to get a new PHYSFS_setRoot. The github submodule source has been changed to one which updates more frequently to get this.
The initial version of the oculus mobile driver incorporated two files, BridgeLovr.cpp and BridgeLovr.h, which were assumed to be outside of the Lovr repo in the repo for a separate Android app. The Android app now is wholly separated and communicates with the Lovr shared object via the interface in oculus_mobile_bridge.h.
A file print_override.c now contains a drop-in replacement for Lua print() which prints to lovrLog. This is useful for Android or for other future platforms where stdout/stderr aren't usable.
The goal is to ensure that (for 3DOF devices) all poses are reported
to include the state.offset vertical transform applied to them. Previously,
only rendering was using state.offset.
This is important to fix spatial audio.
Is doing this in every driver problematic? What if we did it in the
Lua bindings? That way it could be handled in one place.
