lovrCheck is a new way of performing runtime assertions.
It's identical to lovrAssert, except it's compiled out if
LOVR_UNCHECKED is defined.
It is meant to be used for non-mission-critical validation, for
example proper usage of types passed to the Lua API. lovrAssert
should still be used to check return values from platform APIs.
- Use incoming depth settings to determine whether depth test should be
enabled or disabled (wtf)
- Always track state.depthTest, even if depth test is disabled
- Previously, animate was converting from oculus basis to lovr basis.
- Not all hand models are animated.
- Instead, apply the compensation in newModel.
- This means that both animated and non-animated models have correct orientation.
- Verified that regular getPose is returning correct rotation as well.
- Previously, animate was converting from oculus basis to lovr basis.
- Not all hand models are animated.
- Instead, apply the compensation in newModel.
- This means that both animated and non-animated models have correct orientation.
- Verified that regular getPose is returning correct rotation as well.
So that projects that use lovr as a submodule can
inject their own plugins.
By picking them up from the _root_ project, whatever project that
is embedding lovr can decide for itself what plugins to use. This
is cleaner than using a separate glob and a variable in the case
where lovr will never come bundled with a standard set of plugins.
If a Texture is created from a handle, that means someone else created
it, so we expect them to destroy it. We were always destroying handles,
and I guess this was usually okay because glDeleteTextures is idempotent.
However, we're seeing a crash in the Oculus driver when OVR is torn
down. Presumably it is trying to access its swapchain textures after we
destroyed them. Not sure why this wasn't an observable issue before,
maybe it's a new regression. Still, it makes sense to only delete the
GL texture handle if we were the one that created it.
We don't need to check this for the renderbuffer since we always own those.