OpenXR provides APIs to enumerate the supported refresh-rates, and
selecting a new refresh-rate. This patch adds two new APIs to the
lovr.headset module:
- lovr.headset.getDisplayFrequencies():
Returns a table containing the supported refresh-rates on
success; nil otherwise.
- lovr.headset.setDisplayFrequency(refreshRate:number):
Returns true on success, false otherwise.
Only the OpenXR backend has support for this feature and it is
gated by the "refreshRate" feature flag, similarly to what the
"getDisplayFrequency()" API does.
When you set C_STANDARD, CMake won't listen and will decay to older
C versions if the one you asked for isn't supported.
You can set C_STANDARD_REQUIRED, but it won't work in VS 2017 and below.
I guess this is better than nothing.
Physics world's "quick step" is executed in multiple iteration steps.
The getter and setter for this value is now made available as two new
methods in the World object.
This is allows user to balance between the less accurate but quick
simulations, and more stable behavior of physics.
Something similar was already possible, by reducing the delta time and
running the sim multiple times per frame. However, any force user applies
to collider is zeroed after each step. User would thus have to keep track
of applied forces, and re-apply them inside the physics iteration loop.
By default ODE uses 20 iterations in quick step.
We don't have a good way of returning filesystem error messages yet,
but it's still useful to return a boolean instead of a number to
detect failure of zero byte writes. Exposing the number of bytes
written is kind of weird since it's not very actionable.
There's a bug where arguments start at 0 instead of 1 in fused mode.
In fused mode, we aren't going to consume one of the command line
arguments for the project path like we normally do, so in order to
provide that argument to the lovr project at index 1, shift them all up
by one in boot.lua. We can only do this after the filesystem module is
loaded, so it can't go in main.c with all the other arg stuff.
The zero'th argument in fused mode is now the source path, just like how
it works in non-fused mode. This means the executable path is in the
arg table twice, which is sensible since in fused mode both the
interpreter and the interpreter's source are the same file.