This upgrades us to the latest master (pre-release) version of GLFW which has our patches
for undefined behavior in Zig, effectively moving us off of our temporary fork. We now track
GLFW upstream at the revision documented in https://github.com/hexops/glfw/blob/main/VERSION
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
Co-authored-by: Cai Bingjun <1945458160@qq.com>
Moving to the same model we use elsewhere: we now have https://github.com/hexops/glfw
which is a tiny repository with only the sources needed to compile/build/test GLFW on
every platform. It's just the upstream repository at a specific commit, recorded in
the `VERSION` file.
Helps hexops/mach#343
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
This switches our ECS over to manually managed memory (1 `[]u8` per archetype table,
with multiple column arrays packed into it - dealing with padding/alignment ourselves)
rather than the prior 1 `ArrayList(Component)` per component in an archetype table.
This idea was discussed in depth in [#ecs:matrix.org](https://matrix.to/#/#ecs:matrix.org)
(thanks Levy!) Notable advantages from my POV:
1. This means we don't need an `ErasedComponentStorage` interface, which is nice.
2. It means component storage does not have to have a Zig type. It could e.g. in theory enable
the ECS to be usable from other languages (C, WebAssembly plugins, etc.) with component types
defined in those languages in the future.
3. It reduces some overhead `ArrayList` has: slice ptr+len+capacity integers per component
array per table
4. It guarantees component arrays are contiguous memory, rather than relying on the allocator
to hopefully provide that (may not hold true in multi-threaded large-allocation situations.)
5. It means we could easily optimize for tables that have very few components by allocating exact
memory for them (could've done this with `ArrayList` too, but now it's more likely the
allocation are larger and thus more reusable by future archetype tables.) This could be quite
important because one can imagine ending up with many small archetype tables.
Overall seems like the right thing to do, so we're doing it.
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
For some characters (eg \r) the returned glyph will have .{.rows = 0, .width=0, .pitch = 0, .buffer = null}. In zig null[0..0] causes a panic rather than returning an empty slice.
