The reason is that the glslang C API doesn't support the extra
overloads that let you provide multiple strings or the lengths for
strings. In our case our shader blobs are not null terminated, so
sending them to glslang would overrun the buffer. I forked glslang
and modified the C API to support a length parameter.
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
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.
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.
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.
- 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.