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.
lovrGraphicsMapBuffer had the potential to cause a flush. Flushing
unmaps buffers. This meant that during any of the calls to map while
creating a Batch, it was possible to cause a flush and unmap other
buffers that expected to be mapped. This caused writes to unmapped
pointers and subsequent skipping of calls to glFlushMappedBufferRange.
The fix is to figure out if we need to flush upfront and get it out
of the way before mapping any buffers.
- Backported the OCULUSGO device type enumerant. Need to test to
determine if the Oculus Go still reports this device type or if
it just reports unknown.
- A more involved fix will be to use JNI to discover the build model
from the Android settings.
Some hardware supports ARB_compute_shader but not 4.3, causing
shader compilation failures because currently we switch to GLSL 430
if compute shaders are detected.
Instead, just detect GL 4.3 instead of looking for the compute shader
extension. This means that compute shaders will sometimes be
unavailable even when they're supported.
It would be possible to improve this by modifying the way shaders
are compiled. Maybe the highest supported GLSL version should be used,
but this makes shader authoring somewhat more difficult.
We never try to do this anyway, and the unmapping code in discard
doesn't flush contents so it's better for people to unmap the
buffer themselves before calling discard.
It appears that GL_MAP_UNSYNCHRONIZED_BIT interferes with
GL_MAP_INVALIDATE_BUFFER_BIT's ability to discard buffer
contents. Removing the unsynchronized bit fixes visual
glitches on Intel HD GPUs.
There are two HOME keys defined in keycodes.h, the previously used
doesn't work and is labeled with the following comment: "This key
is handled by the framework and is never delivered to applications."
OpenXR basically has a hard requirement that a graphics API is available
before its session can be created. Currently the graphics module isn't
always around when headset initialization takes place. Polling the
graphics availability in update/renderTo has some consequences for calls
made to the headset module in lovr.load or during the first few frames.
So instead we're going to delay headset initialization to a special
function that is called after modules are required. It can also be
called manually if the window creation is delayed.
- Make the renderloop synchronous by hijacking the RAF to run on the
XRSession when active.
- Convert os_web to use emscripten's native HTML5 interface instead
of going through GLFW.
- Stop using preinitialized GL context -- lovrPlatformCreateWindow
now creates the context.
- GLES2/3 emulation is not necessary.
- Remove inline sessions. The VR simulator is used to render to the
Canvas instead. webxr_attach and webxr_detach are used to replace
replace the active headset driver with the webxr driver when an
immersive session starts.
- Add noop desktop_getSkeleton.
It doesn't need to check it for RGB and compressed textures because
those are already rejected.
It may also be a good idea to zero-out the srgb flag for formats that
it doesn't apply to.
- lovr.headset.newModel accepts an optional options table as the
second argument. There is currently a single option named
'animated' that can be used to request an animatable model.
Currently it isn't clear if this should be a hint or not.
- lovr.headset.animate (name pending) can be called with a device
and a model (usually with an animated model from headset.newModel,
but this is not required). The function attempts to animate the
Model to match the pose of the device in an opaque driver-specific
way, and returns whether or not this was successful.
- OpenVR has models for controllers with a system called "components"
that can be used to animate the individual buttons. Now the OpenVR
headset driver implements the 'animate' function to make use of the
controller components, to easily load and render animated controllers.
ModelData manages a single allocation and creates pointers into
that allocation. These pointers were tightly packed, creating
alignment issues which triggered undefined behavior. Now, the
pointers are all aligned to 8 byte boundaries.
* lovrPlatformGetBundlePath was missing the root argument
* ANDROID_SDK can't be assumed to be the parent of the ndk folder, in case it's a side-by-side installation of the NDK. Instead, ANDROID_SDK should be provided with -D
* One more thing we could mention in the docs that I ran into: Installing java with apt gave me an incompatible version. It worked better to just -DJAVA_HOME= to the java that comes with Android studio (/snap/android-studio/91/android-studio/jre on ubuntu).
There are some attributes that don't have a location (gl_InstanceID
is being reported for some reason). Their location is -1 and this
causes a left shift of a negative value which is undefined.
The new t.graphics.debug flag controls the following:
- If enabled, a debug context is created
- If disabled, a no-error context is created
- If enabled, GL debug messages are forwarded to lovr.log
Add entrypoints, headset backend code, fill in the Activity, and
add various special cases to account for the asynchronous render loop,
lack of sRGB support, and OpenGL state resets.
I added header files with #include to prevent the implicit declaration warnings and fixed a typo in function size_t lovrPlatformGetExecutablePath(char* buffer, size_t size).
lovr.log is a new callback that is invoked whenever LÖVR wants to
send the project a message. For example, this could be a performance
warning from the graphics module, an error message from one of the
headset backends, or an API deprecation notice.
The callback's signature is (message, level, tag). The message is a
string containing the message to log, level is a string that is currently
one of "debug", "info", "warn", "error", and tag is an optional string
that is used to indicate the source of the message for grouping purposes.
The default implementation of the callback just prints the message,
but the callback can be overridden to do things like filter messages,
write them to a file, or even render them in VR. Projects can also
invoke the callback directly to log their own messages.
Usually these are more of a platform-specific concept, and they
don't really interact with files or do any io.
There is a little bit of duplication among the *nix platforms since
they're similar, but overall this organization feels a bit better.
With the check for samples==0 being done BELOW the assert for offset+samples<soundData->samples,
setting samples to 0 and then having more samples available in the mic than present in
the created buffer would cause buffer overrun
Tightness parameter is amount of force is exerted on collider to resolve
collisions and enforce joint operation. Low values make joints loose,
high values make it tight and can cause collider to overshot the joint
target. With tightness set to 0 the joint loses its function. Going
above 1 puts even more energy into joint oscillations. Tightness
parameter is called ERP in ODE manual.
The responseTime affects the time constant of physics simulation, both
for collisions and for joint inertia. Low responseTime values make
simulation tight and fast, higher values make it sluggish. For
collisions it affects how fast penetration is resolved, with higher
values resulting in spongy objects with more surface penetration and
slower collision resolving. For joints the responseTime is similar to
inertia, with higher responseTime values resulting in slow oscillations.
The oscillation frequency is also affected by collider mass, so
responseTime can be used to tweak the joint to get desired frequency
with specific collider mass. Values higher than 1 are often desirable,
especially for very light objects. Unlike tightness, responseTime is
tweaked in orders of magnitude with useful values (depending on mass)
being between 10^-8 and 10^8.
Both parameters can be applied to World for simulation-wide usage, or
specified per-joint in case of distance and ball joints. Other joints
don't allow customizing these parameters, and will use World settings
instead..
When creating shapes and joints, arguments accept either coordinate
numbers as before, or vec3 objects. For functions that receive more than
one set of coordinates, any combination of coordinates and vectors is
accepted.
There are 4 new devices: beacon/1 through beacon/4. They represent
tracking reference like StemaVR base stations or Oculus cameras.
There are 4 because that's how many base stations you can have in
a single tracking setup.
Right now only OpenVR exposes poses for them.
When creating colliders, setting gravity or casting rays on world,
arguments accept either coordinate numbers as before, or vec3 objects.
For functions that receive more than one set of coordinates, any
combination of coordinates and vectors is accepted.
ModelData is still allowed to load skins with more joints, since
the limitation is in the graphics side of things (Model).
Eventually we will use a buffer for joints to alleviate this.
This was originally a C++-only contribution, but clang also warns
about it on windows when compiling as C.
It's nice to have one less thing specific to C++.
GL_DEPTH_TEST controls both whether depth testing and depth writes are
enabled. So if depth testing is disabled and depth writes are enabled,
GL_DEPTH_TEST has to be enabled and the compare mode should be GL_ALWAYS.
Based on Slack conversation, the following changes:
- lovr.event.quit("restart") no longer supported
- lovr.event.quit no longer takes restart "cookie"
- When lovr.event.restart() called, lovr.quit() is not called, instead lovr.restart() is called
- Value returned from lovr.restart(), when called, becomes the cookie
- lovr.event.quit takes the lovr.event.quit() return code as an argument
lovr.run() is unchanged, it still returns (exit code | "restart", cookie).
as mentioned on slack.
there are some situations you can get into (high load in some place or other) where the newer frame submission api will behave much more consistently, and I've noticed no negative effects.
besides, the other one is deprecated as best i can tell.
- There is now just one "playing" state.
- Instead of rewind, use :seek(0).
Note that now there is no way to resume or rewind all tracked sources.
This can be improved in the future if there's a need for it, probably
using variadic or table-based variants of the audio module functions.
Lua was happily compiling nil chunks and making them return empty
strings, which was not a good error experience in situations where
your file couldn't be loaded properly. Now we return nil plus an
error message, which matches LOVE and other Lua conventions.
A cast is required at this point in MSVC 2019 when ref.h is included from a C++ file. This change has no effect on Lovr compiled normally (which compiles only as C), what this change does is make it possible for forks to extend Lovr with C++ files.
Nodes can have either a transform matrix, or decomposed transform
properties, but never both. Using a union means we can store both
of those variants in the same piece of memory, using the existing
matrix boolean to figure out which one to use.
This reduces the size of the struct by 48 bytes (152 -> 104), which
ends up speeding up some model operations, I'm guessing due to the
CPU cache.
Unlike lovr.timer.getTime, this is the predicted time at which the
current frame will be displayed. It can be used in place of
lovr.timer.getTime for smoother animations. It's unclear if this
could be used for a suitable replacement for dt though.
Currently nobody returns data for them, though headset drivers could
start to provide poses estimated from the head pose and IPD info.
This also makes it easier to integrate eye tracking later.
The previous implementation relied on glShaderSource inferring source
lengths when the lengths weren't specified. This relies on the sources
being properly null-terminated, however, which isn't the case due to
file loading changes which now use pointer + length. This could cause
intermittent crashes.
Changing this on the shader side meant adding some extra arguments for
passing around shader source lengths. For most of the other cases, where
we're using string literals as the sources, we can just specify -1 as
the length, since OpenGL will calculate the string length for you any
time the length is negative.
This is a change that shifts the responsibility regarding the creation
of OpenGL framebuffers from vrapi-provided swapchain texture handles.
Previously, the LovrApp component of lovr-oculus-mobile was creating
framebuffers and passing native framebuffer IDs to lovr. With this
change, lovr-oculus-mobile passes vrapi's swapchain textures to lovr
unmodified. This allows lovr to create canvases using its conventional
method and also means that the properties of the canvases are no longer
hardcoded, so things like resolution and multisampling can be
customized.
There were also some issues with multiview canvases in LÖVR due to some
misconceptions about how multisampled multiview rendering works. These
issues have also been fixed in this commit.
conf doesn't work in threads. While this seems problematic, it can
kinda be considered the right thing. Right now the math module can't
be required at all in threads which seems bad, so we'll make it work
and just ignore the "globals" flag for now.
Apparently requesting/rendering zero vertices was clogging stuff
somewhere. It seems good enough to just explicitly not render
anything if we weren't gonna do it anyway.
It's causing massive problems on windows, and sleeping for zero ms
is good enough to relinquish CPU time to the OS. VR APIs also do
their own sleeping.
Previous code would wastefully reallocate memory for every time a buffer is too big to fit. New code just uses an index into the next buffer at which to start reading, requiring no extra allocation.
Instead of having a bogus samples ivar in AudioStream when it's raw, use it to denote the amount of audio data enqueued.
This means `stream:getDuration()` gets the same meaning as `stream:getQueueLength()` (except in seconds instead of samples), so we can remove the latter.
Before, streams were rewound when they stopped, so that next time they're played they're played from the start.
Instead, rewind on play instead, so that it's done when it's needed. This gets us a good point to make sure we're not rewinding raw streams too.
- Teach CMake how to compile binary resources to C headers, like xxd.
- Note: tup is already using xxd to do this.
- gitignore binary resource headers to reduce git noise and avoid problematic
interactions between git and build systems.
This allows for headless operation. Currently GLFW throws an error
if you call glfwInit without an X server running, preventing lovr
from starting at all in that situation.
Because GLFW is currently used for time functions, those had to be
moved into the platform layer. There's lots of duplication here,
ideally the platform layer would just return raw timer values and the
timer module would handle the epoch logic, but it was too difficult to
coordinate that right now.
Also, lovrPlatformInit is guaranteed to set the time epoch to 0 now.
- One toplevel Tupfile that makes it more clear what happens.
- Add config flags for -Werror, -fsanitize, and separate debug/optimize flags.
- Automatically integrate with libs built by CMake (build folder, rpath, libs folder).
- Disabling modules actually works, only the stuff that's needed is built.
Channels need to be removed from the global array/map when destroyed.
Note that this exposes an infinite loop in map_remove, which will
be fixed later.
Note also that Channel's are retained if they have any messages in
them, to prevent releasing a channel while it has pending messages.
Calling objc_msgSend with its vararg signature will only work most
of the time, and fail very weirdly when it doesn't. It's weird,
but you're supposed to always cast it to the signature of the
selector you're calling.
I think this is even required when building on Catalina, or for arm64?
Currently:
- load/update/run/etc. take place on the boot.lua coroutine.
- draw happens "asynchronously" on the main thread.
When C needs to throw an error, it doesn't know which thread to
throw the error on. If it throws it on the wrong thread, you get
a crash instead of an error screen.
One way to fix this is to change the error context based on the
thread that's currently running, so that errors in C are thrown
on the correct thread. This is the approach that's taken here.
A potentially better approach would be to run all the code on the
same thread, but I ran into issues when I tried to do this.
It may also be possible to (ab)use the Lua panic handler to catch
errors on one of the threads and somehow forward them to the other.
- lovr.graphics.tock returns the latest value of the timer, or 0.
- Timers are not in the stats table anymore.
This is to prepare for an upcoming internal change that affects timers.
This means Lua print() statements can be uniquely filtered out vs anything else (because internal Lovr logging uses loglevel DEBUG and lovr errors use loglevel WARN).
The "mask" example was failing on Oculus Mobile on the line of glsl:
if (lovrViewID == 1) {
because lovrViewID was unsigned and 1 was signed. One way to fix this would be to replace 1 with 1u as that is unsigned, but this would be the wrong fix because lovrViewID is in fact signed on all platforms other than Oculus Mobile. lovrViewID was depending on platform defined to either gl_ViewportIndex (signed), a signed uniform, or gl_ViewID_OVR (unsigned). The solution is to place an explicit cast in the multiview definition of lovrViewID so that it is signed on all platforms.