Zero as default makes more sense. Colliders can come to full stop which
allows them to go to sleep for CPU optimization. Also in zero gravity
colliders crawling through air with 0.01 velocity are infuriating.
It seems to me like that lovrRelease will delete textureData->blob immediately,
which means the windowing system later can't use it because it's already freed.
There's already a free on line 378 which looks more correct.
Also, icon appears flipped if 'flipped' is set to true here on Linux. Is GLFW
inconsistent between linux and windows, or should it indeed be false?
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.