Previously, this program function lovr.update(dt) lovr.filesystem.append("/test123", lovr.timer.getTime()) end would fail in lovr because lovrFileWrite required the file to be in write mode (not append)
l_event.c was processing a thread-related event and in the process using a thread struct, even when LOVR_ENABLE_THREAD is undefined and threads do not exist. I caused the thread event type to simply not exist when the thread module is not being built.
Since the event is now only sometimes present, I put it at the end of the enum as slight protection against binary mismatches with dynamically loaded modules.
Because of how and when draws occur in our Oculus Mobile path, during a restart it would attempt to draw a frame after lovrGraphicsDestroy() is called, leading to a crash in lovrGraphicsSetCamera(). This blocks draws until the restart is finished and renderTo() has been called (conveniently detectable using the existing state.renderCallback).
Empty arrays aren't allowed in C++, so a single dummy element has to be added. sds works by scary cast magic so this dummy element is never actually allocated. A #define is used in this patch so in C this compiles exactly the same as before.
Check for GCC version >=4.7 [covers GCC or, theoretically, Intel C Compiler] or __has_builtin(__atomic_add_fetch) [covers Clang]. If either of these are found, prefer the GCC atomic builtins instead of the C11 builtins.
Also: Gates Microsoft atomics on _MSC_VER, not _WIN32. This may help improve compatibility with mingw but has not been tested.
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.
mat4_transform ignores the final row of the matrix, which normally contains scale data. This is fine for modelview matrices, which is all lovr currently uses mat4_transform for. However it fails if you ever use mat4_transform on a projection matrix.
mat4_transform_project takes the final row into account, so you can use it with projection matrices. This was useful in my fork and might be useful to have around in lovr someday later.
- 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).
- Slightly dim background color (may change).
- Use a shader for the logo (it's centered now, not quite 100% like the image).
- Adjust text optical weight (I hate it).
Returns the predicted display time, which is the estimated time at which
the photons of the next frame will hit the eyeballs of a person in the HMD.
This should be used instead of lovr.timer.getTime when used for rendering
something that is time-dependent. Updating simulations, logic, or access
to high frequency times should still use lovr.timer.getTime.
- 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.
mcc
bjorn