A lot of clean up can happen now that C doesn't push delayed errors to
Lua. This was happening for Pico and WebVR, neither of which are used
anymore.
Also default vsync to true but force it off if VR is active.
The sync was totally wrong here. It's a bit better now. However there
are some general sync issues that need to be fixed. Basically a Pass
that does reads and writes or multiple writes doesn't work properly, for
various reasons. I think sync needs to be split into 2 phases -- first
process all the reads and merge barrier bits into the barrier of the
last writer, then process all the writes and set 'final' resource state
for stuff in the pass. Due to branch prediction it may be better to
have 2 separate lists -- one for reads and one for writes. And I'm not
100% sure on how to reconcile a Pass that is doing reads and writes to
the same resource yet, still thinking about it.
It uses newPass instead of getPass. Temporary objects had lifetime
issues that were nearly impossible to solve. And normal objects are
easier to understand because they behave like all other LÖVR objects.
However, Pass commands are not retained from frame to frame. Pass
objects must be re-recorded before every submit, and must be reset
before being recorded again.
Pass objects now provide a natural place for render-pass-related info
like clears and texture handles. They also allow more information to be
precomputed which should reduce overhead a bit.
It is now possible to request a stencil buffer and antialiasing on the
window and headset textures, via conf.lua.
lovr.graphics.setBackground should instead set the clear color on the
window pass. Though we're still going to try to do spherical harmonics
in some capacity.
There are still major issues with OpenXR that are going to be ironed
out, and the desktop driver hasn't been converted over to the new
headset Pass system yet. So lovr.headset integration is a bit WIP.
There are some issues with immediately tracking readbacks in the global
linked list of pending readbacks:
- The Pass might not get submitted, in which case the readback will be
"dangling" and never complete (or it will erroneously think it's
completed but its buffer will contain garbage data).
- Thread safety issues of modifying a global data structure from a Pass.
Instead, Pass will locally track the readbacks it performs, and only at
submit time will those readbacks get added to the global list.
(There is a little bit of refcounting mistakes now, those will get
cleaned up).