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.