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.