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..
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.
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.
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.
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.
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.
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.
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.
- 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).
Instead of boolean shader flags turning into actual booleans defines
in the shader source, for GLSL they turn into defines. This lets you
use ifdef, which is the more common intended usage.
Also MULTICANVAS is now a boolean shader flag. The old MULTICANVAS
define is deprecated.
Previously, this program function lovr.update(dt) lovr.filesystem.append("/test123", lovr.timer.getTime()) end would fail in lovr because lovrFileWrite required the file to be in write mode (not append)
l_event.c was processing a thread-related event and in the process using a thread struct, even when LOVR_ENABLE_THREAD is undefined and threads do not exist. I caused the thread event type to simply not exist when the thread module is not being built.
Since the event is now only sometimes present, I put it at the end of the enum as slight protection against binary mismatches with dynamically loaded modules.
Because of how and when draws occur in our Oculus Mobile path, during a restart it would attempt to draw a frame after lovrGraphicsDestroy() is called, leading to a crash in lovrGraphicsSetCamera(). This blocks draws until the restart is finished and renderTo() has been called (conveniently detectable using the existing state.renderCallback).
Because the new arr.h contains an array on the stack, we can't
initialize it and then copy it, or the pointer to the stack array
will be pointing to the wrong thing, causing incorrect behavior.
- If you have an instanced batch, it will use the instanced mesh. That
has a drawID attribute that uses the identity buffer, which has a vertex
divisor. BUT if you only have one instance, then we won't emit an
instanced draw, and the use of a divisor'd attribute w/ a non-instanced
draw is causing mega problems on macOS.
- This also fixes observed macOS bugs like:
- Needing to have a small UBO
- Flickering at startup
- Flicker when writing to the last byte of a UBO
- etc.
- Also make the generic attribute value for lovrDrawID more correct (scalar instead of vector).
Returns the predicted display time, which is the estimated time at which
the photons of the next frame will hit the eyeballs of a person in the HMD.
This should be used instead of lovr.timer.getTime when used for rendering
something that is time-dependent. Updating simulations, logic, or access
to high frequency times should still use lovr.timer.getTime.
- Rename drawMode to topology in some places.
- Batch uses DrawCommand internally to simplify stuff.
- Do less work while flushing.
- Store global head/tail cursors instead of unused per-batch cursors.
- Reduce number of batches to 4. Yeah it's arbitrary, will monitor.
- Just use memcmp for BatchParams. Since we're using designated initializers,
we aren't running into issues with memcmp+struct padding bits, and in the
event it does lead to false positives on some platforms, at worst we'll just
experience a harmless reduction in batching efficiency.
Currently, we gamma correct colors on every clear and every draw.
It's taking a lot of time. Instead, we'll gamma correct colors
when they're changed using lovr.graphics.setColor/setBackgroundColor.
Having a normal Canvas object that represents the backbuffer reduces
some indirection where we have to last-minute check if a Canvas is
set. It also means that all of the draw-related info that was _sometimes_
on the Canvas is now _always_ on the Canvas, which reduces the amount
of redundant information we need to provide for a draw call.
There may be some issues related to changing the width/height/stereo
of the default Canvas.
It's still a rough draft and likely only works on my machine, but can be
improved over time.
Rough explanation:
- tup.config contains high-level build configuration defaults.
- Tuprules.tup contains mostly compiler flags (generated from the
tup.config) and declares some macros used to compile code.
- Tupfile takes all generated object files and links them into the
lovr executable.
- src/Tupdefault defines the default build steps for src and all
subdirectories, which is to compile all .c files to .o files and put
them in the <objects> bucket for linking by the toplevel Tupfile.
It's possible to have multiple configs active at once for different
platforms, projects, etc. To do this, create a folder for each build
variant you want, and place a tup.config in each folder (it can be a
symlink, which is helpful). Then, invoking `tup` will build all your
variants, or you can build a specific one by doing `tup <foldername>`.
- Ref struct only stores refcount now and is more general.
- Proxy stores a hash of its type name instead of an enum.
- Variants store additional information instead of using a vtable.
- Remove the concept of superclasses from the API.
- Clean up some miscellaneous includes.
If we expose both unhanded hands and handed hands, people need to
deal with handling (haha) both cases in their apps. It's simpler
to always deal with left and right hands, even though it is a bit
less general. Still, this is congruent with the current state of
OpenVR and OpenXR, and I think there are still open questions about
the more uncommon cases where there are more than two hands.