We know what type we're releasing 99% of the time, we don't need to
play a guessing game in lovrRelease, just have the caller say which
destructor to use.
There is lovrGenericRelease for situations where we need it, which
does the slower lookup of the destructor.
This requires adding an application id function to platform and adding a mini definition to sds into platform.h. All platforms except Android return NULL (no application id)
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
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.
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.