This includes the memory allocator and the morgue.
You can't actually write any data to the buffer yet, since we don't have
commands or temp buffers. Temp buffers (scratchpads) are coming soon.
- rm dynamicIndexing and nonUniformIndexing, for now (arrays aren't well
supported)
- rename compressed texture features
- move clip/cull distance to limit instead of feature (limit can be 0)
Notes:
- We can actually use a single Activity.java file for oculus/pico now
- We can unconditionally compile os_android.c on Android
- No need for including extra jars in build system
- Headset rendering is guaranteed synchronous now, no need to ref L
- Add an "android flavor" build setting to differentiate between oculus
and pico devices, since they both use OpenXR.
- Update the pico manifest to reflect their OpenXR sample
- Remove some OpenGL hacks that aren't necessary anymore
Currently there is a single allocator function used in arr_t. Its
behavior depends on the values for the pointer and size arguments:
- If pointer is NULL, it should allocate new memory.
- If pointer is non-NULL and size is positive, it should resize memory.
- If size is zero, it should free memory.
All instances of arr_t use realloc for this right now. The problem
is that realloc's behavior is undefined when the size argument is zero.
On Windows and Linux, realloc will free the pointer, but on macOS this
isn't the case. This means that arr_t leaks memory on macOS.
It's best to not rely on undefined behavior like this, so let's instead
use a helper function that behaves the way we want.
The current flag did not work because float shader flags are not
supported. It was also not very useful because it was per-shader
and did not use the alpha cutoff property of glTF materials.
Instead, let's turn the shader flag into an enable/disable boolean,
and add a scalar material property named "alphacutoff" that gets
read by the glTF importer.
When the alphaCutoff flag is enabled, the material property will be
compared against the pixel's alpha value to decide whether it should
get discarded.
- When calling lovr.graphics.stencil, the color mask is initially
disabled, and gets restored to its initial state afterwards.
- However, when it's restored, it uses lovrGraphicsSetColorMask, which
just sets shadow state that doesn't make it all the way to GL until
another draw is done.
- The consequence of this is that if you call .stencil and then don't do
a draw, any clears that happen will use the old (disabled) color mask,
preventing the color buffer from being cleared.
- The solution here is to lower the color mask change down into opengl.c
where it can directly hit OpenGL.
- 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
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.
- Compute feature requires compute shaders, image load/store, and SSBOs.
- GLSL 330 is always used, instead of changing depending on compute shader extension.
- Explicitly enable compute shaders, image load/store, and SSBO extensions when needed.
This allows implementations that don't support GLSL 430 to run compute shaders,
and keeps the min supported GL version more consistently at GL3.3.
Headset drivers are allowed to override the vsync setting if vsync
messes up their frame timing. The vsync property is effectively a
global piece of state in core/os and doesn't change across restarts
because the window is persistent. This can mean that if you switch
from a headset driver that wants vsync off (anything except desktop)
to a headset driver that doesn't care what the vsync is (desktop),
you could end up with a vsync setting that doesn't match t.window.vsync.
I think this is a symptom of poor design somewhere and the best solution
to this probem is "to just not have it". Similar issues exist for, e.g.
the window size (but that one is less weird because at least you were
the one who changed it). For now we are just going to ensure that
lovr.graphics.createWindow always modifies the vsync property.
Untested, may need to adjust this fix later.
lovrGraphicsMapBuffer had the potential to cause a flush. Flushing
unmaps buffers. This meant that during any of the calls to map while
creating a Batch, it was possible to cause a flush and unmap other
buffers that expected to be mapped. This caused writes to unmapped
pointers and subsequent skipping of calls to glFlushMappedBufferRange.
The fix is to figure out if we need to flush upfront and get it out
of the way before mapping any buffers.
Some hardware supports ARB_compute_shader but not 4.3, causing
shader compilation failures because currently we switch to GLSL 430
if compute shaders are detected.
Instead, just detect GL 4.3 instead of looking for the compute shader
extension. This means that compute shaders will sometimes be
unavailable even when they're supported.
It would be possible to improve this by modifying the way shaders
are compiled. Maybe the highest supported GLSL version should be used,
but this makes shader authoring somewhat more difficult.
We never try to do this anyway, and the unmapping code in discard
doesn't flush contents so it's better for people to unmap the
buffer themselves before calling discard.
It appears that GL_MAP_UNSYNCHRONIZED_BIT interferes with
GL_MAP_INVALIDATE_BUFFER_BIT's ability to discard buffer
contents. Removing the unsynchronized bit fixes visual
glitches on Intel HD GPUs.
It doesn't need to check it for RGB and compressed textures because
those are already rejected.
It may also be a good idea to zero-out the srgb flag for formats that
it doesn't apply to.
There are some attributes that don't have a location (gl_InstanceID
is being reported for some reason). Their location is -1 and this
causes a left shift of a negative value which is undefined.
The new t.graphics.debug flag controls the following:
- If enabled, a debug context is created
- If disabled, a no-error context is created
- If enabled, GL debug messages are forwarded to lovr.log
Add entrypoints, headset backend code, fill in the Activity, and
add various special cases to account for the asynchronous render loop,
lack of sRGB support, and OpenGL state resets.
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.
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.
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.
- 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.
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.
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).
- 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.
- 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.