30e01f upgraded stb_image to include its 95560b commit from its #960
pull request. This made stb_image fail more aggressively on EOF
conditions when refilling huffman buffers in deflate streams. I think
it might be failing _too_ aggressively, though. We are able to pad our
input compressed buffers since the zip file format is guaranteed to have
extra data at the end (for, e.g., the end of central directory record).
This appears to be sufficient to fix compressed zip archives for the
time being. It's possible that more virtual padding needs to be added,
and it may be good to try to fix this in stb_image itself.
The falloff is the minimum distance at which inverse distance
attenuation takes place.
A non-positive value disables distance attenuation.
In the Lua API, nil can be used to disable attenuation, a boolean can be
used to enable attenuation with a default minimum distance, or a number
can be used for full control over the parameter.
Add support for importing ambisonic WAV files and 24/32 bit PCM WAV files.
The standard ambisonic format used internally in LÖVR is ACN channel ordering with SN3D normalization.
Anything else will be converted to this form.
There are a few restrictions and assumptions:
- Only 1st order ambisonics are supported. They need to have 4 channels.
- They can be in AMB format (Furse-Malham order/normalization), detected via WAVE_EXTENSIBLE GUID.
- Any other 4 channel file is assumed to be in "AmbiX" ACN/SN3D format.
- It seems that most ambisonic files in the wild that claim to be AmbiX are just 4 channel WAVs without any metadata.
- This means that non-ambisonic 4 channel WAVs could ambiguously be mistaken as ambisonic. This is incurred as a limitation of LÖVR.
- Ambisonic files can not currently be played back. SteamAudio currently has numerous bugs with this.
- Perhaps it would be possible to write an ambisonic rotator/panning decoder to use as a default implementation.
- Compute feature requires compute shaders, image load/store, and SSBOs.
- GLSL 330 is always used, instead of changing depending on compute shader extension.
- Explicitly enable compute shaders, image load/store, and SSBO extensions when needed.
This allows implementations that don't support GLSL 430 to run compute shaders,
and keeps the min supported GL version more consistently at GL3.3.
If 64 sources are playing and a new one is started, Source:play will
return false.
Instead of a linked list, a static list of 64 Sources is used.
Bit scanning intrinsics are used to efficiently iterate the list,
using a mask (still deciding on this).
It isn't always correct once you add locomotion to a project, and
it actually becomes harmful because the pose ping-pongs between
the default pose and the user pose, causing distortion.
- If no converter is needed, don't create/use it
- If no spatialization is needed, don't copy
In the best case, samples willi now be read into a buffer and immediately mixed into the output.
This is a large patch which adds a new Oculus Audio spatializer. Oculus Audio is slightly different from the dummy spatializer in a few ways:
- It *must* receive fixed-size input buffers, every time, always.
- It can only handle a fixed number of spatialized sound sources at a time.
- It has a concept of "tails"; the spatialization of a sound can continue after the sound itself ends (eg echo).
Changes to audio.c were needed to support Oculus Audio's quirks:
- audio.c now supports a "fixedBuffer" mode which invokes the generator/spatializer in fixed size chunks
- Each source now has an intptr_t "memo" field that the spatializer may use to store whatever (Oculus spatializer uses this to handle the sound source limit).
- The spatializer interface got a couple new methods: A "tail" method which returns a sound buffer after all sources are processed; and "create" and "destroy" methods that are called when a sound source is created or destroyed (Oculus spatializer uses this to populate/clear the "memo" field).
Along the way some other miscellaneous changes got made:
- lovr.audio.getSpatializerName() returns the current spatializer
- Spatializer init now takes in "config in" and "config out" structs (Spatializer changes fields in config out to request things, currently fixed buffer mode).
- lovr.conf now takes t.audio.spatializer (string name of desired spatializer) and t.audio.spatializerMaxSourcesHint (Spatializers with max sources limits like Oculus will use this as the limit).
- audio.c went back to tracking position/orientation as vectors rather than a matrix
- A file oculus_spatializer_math_shim.h was added containing a minimal copypaste of OVR_CAPI.h from Oculus SDK to support a ovrPoseStatef the spatializer API needs. This may have license consequences but we are probably OK via a combination of fair use and the fact that a user cannot use this header file without accepting Oculus's license through other means.
Some work remains to be done, in particular there is an entire reverb feature I did not touch and LOVR_USE_OCULUS_AUDIO cannot be activated from tup. Oculus Spatializer works better when it has velocity and time information but this patch does not supply it.
* Stop also uninitializes
* Reset doesn't exist. Just stop and start instead.
* lovrAudioInit no longer takes config, and config is now private.
Call lovrAudioStart if you want to start.
* ma_device_{un}init and start/stop are only called from one place each,
reducing the risk of dangling state
* Takes device type, so you only get either playback or capture devices
* Doesn't store devices in state, reducing risk of dangling pointers
* Uses names instead of identifiers, since miniaudio identifiers become
invalid if you call "getDevices" again
* Better diagnostics
* Split up lovrAudioInitDevice to be per-type, cleaner that way
* UseDevice now takes type and name, instead of just identifier
aka a9541579f38a0c1bab4bba294f3602fa0b80f127, plus cherry-pick of
2dc604ecde0f02280690c72f943bfb8bf52dd820.
There is a crasher in 0.10.13 and newer on Oculus Quest
(See https://github.com/mackron/miniaudio/issues/247)
they take the same arguments so we can't overload
the function parameterically.
also I find it pretty confusing that lovr uses
overloads so much in the api,
so I really don't mind having
a separate constructor :S
By looking for failed start and requesting then;
and then emitting a new event type when
permission has been granted or rejected;
and then using that event in the default
boot.lua to re-start capture.
- The lovr.headset.renderTo callback can now be nil, causing an empty frame to be submitted to the compositor.
- lovr.mirror will still be called if lovr.draw is nil. This means the window will be (correctly?) cleared to the background color now if lovr.draw is nil.
This prevents runtimes from thinking the app is missing/unresponsive when lovr.draw is absent. To get the old behavior, just don't call lovr.headset.renderTo.
lookAt() returns view matrix that can be used to transform the camera
perspective. target() returns model matrix that is used to change
model transform. Results are matrix inversions of one another. Now both
functions exist it is possible to use right one and avoid extra matrix
inversion.
- Link against dl (this was probably why ffi.load didn't work)
- Store shared libraries in the apk uncompressed
- Libraries are added during the "package" aapt call instead of "add".
- Because -0 (used to store uncompressed) only works during package.
- classes.dex is added here too now.
- There's only one aapt invocation now, which is kinda nice.
- The lib folder needs to be in a subfolder now ("raw" was chosen).
- Because "package" and "add" subcommands work differently.
- Store shared libraries in the apk page aligned
- Required passing -p to the zipalign invocation.
- This is needed because dlopen("zip!path") needs it.
- android:extractNativeLibs="false" is added to the XML manifest.
- apk sizes are bigger, but disk usage and install time should improve.
- Fix a bug with moving plugin libraries into the lib folder with CMake.
- Use lovrFilesystemGetSource instead of lovrFilesystemGetExecutablePath
to get the proper path to the apk.
- The plugins folder can contain native plugins.
- CMake will build plugins with CMakeLists in them
- They can check the LOVR variable to see if they are being built inside LOVR.
- They can set the LOVR_PLUGIN_TARGETS variable to a list of targets they build.
- If blank, all non-imported targets added in the folder will be used.
- The libraries built by their targets will be moved next to the executable or into the apk.
- The library loader now tries to load libraries next to the executable or in the APK.
- It is "fixed function" now, this may be improved in the future.
- The lovr.filesystem C require path has been removed.
- enet and cjson have been removed. Use plugins.
stb_image's vertical flip flag was not thread safe in the version
of stb_image we were using. We patched stb_image to use a thread
local variable for the flag. stb_image has since been upgraded to
expose a thread local version of the flag, so our patch is no longer
necessary after upgrading.
The CMake flag to enable the thread local patch did not make very much
sense because thread local stuff is unconditionally used elsewhere.
In boot.lua, it assumes that lovr.headset.init will assert if no driver
is available. This was previously only true on the first call to it,
since after it's initialized, it'll just return early and won't assert.
This will later crash since your lua code will now see a lovr.headset
being available, but calling anything in it will crash since
lovrHeadsetDisplayDriver is NULL
After this fix, initialized becomes false before boot sets up the
headset module again, so that the assertion fires correctly.
Zero as default makes more sense. Colliders can come to full stop which
allows them to go to sleep for CPU optimization. Also in zero gravity
colliders crawling through air with 0.01 velocity are infuriating.
It seems to me like that lovrRelease will delete textureData->blob immediately,
which means the windowing system later can't use it because it's already freed.
There's already a free on line 378 which looks more correct.
Also, icon appears flipped if 'flipped' is set to true here on Linux. Is GLFW
inconsistent between linux and windows, or should it indeed be false?
Headset drivers are allowed to override the vsync setting if vsync
messes up their frame timing. The vsync property is effectively a
global piece of state in core/os and doesn't change across restarts
because the window is persistent. This can mean that if you switch
from a headset driver that wants vsync off (anything except desktop)
to a headset driver that doesn't care what the vsync is (desktop),
you could end up with a vsync setting that doesn't match t.window.vsync.
I think this is a symptom of poor design somewhere and the best solution
to this probem is "to just not have it". Similar issues exist for, e.g.
the window size (but that one is less weird because at least you were
the one who changed it). For now we are just going to ensure that
lovr.graphics.createWindow always modifies the vsync property.
Untested, may need to adjust this fix later.