Commit graph

23 commits

Author SHA1 Message Date
Stephen Gutekanst
b6f41b3fb0 ecs: update to latest Zig build API
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
2023-02-12 10:05:03 -07:00
Stephen Gutekanst
8c72c124e2 ecs: update to latest Zig build API
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
2023-02-12 10:05:03 -07:00
Stephen Gutekanst
2532436170 ecs: cleanup documentation
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
2023-01-28 14:00:21 -07:00
Ali Chraghi
168a84805a ecs: saturated add
Fixes #409
2023-01-15 08:31:26 -07:00
Stephen Gutekanst
a750e31d11 Revert "all: build: fix sdkPath for relative @src.file / fix autocompletion with ZLS / IDEs (#661)"
This reverts commit a1fe671db8.

Lue suggested reverting #661 because ZLS worked around the issue of @src
being relative in that environment: https://github.com/zigtools/zls/pull/898

This is not a perfect solution (what zls did seems to be a workaround), but
is good enough for us until Zig gets an official package manager.
2023-01-10 01:57:52 -07:00
Lue
a1fe671db8
all: build: fix sdkPath for relative @src.file / fix autocompletion with ZLS / IDEs (#661)
* all: build: fix sdkPath for relative @src.file

Prior to this commit, the build system heavily assumed that the result
`@src.file` would always be absolute, but this is no longer
guaranteed, likely due to there being no such thing as an "absolute
path" in WASI.

It appears that for normal invocations of `zig build`, it is safe to
assume that `@src.file` is absolute. However, when ZLS uses a custom
`build_runner.zig` to collect build configuration, `@src.file` is
actually relative to the current working directory, at least on my
system. For a while, this led to ZLS completions breaking entirely,
but presently it actually causes ZLS to crash!

The solution is not as simple as using relative `sdkPath` results
as-is, because the build system may attempt to resolve these paths
relative to build root, when the paths are actually relative to the
current working directory.

This leads to a sticky situation: the current working directory is a
runtime concept, but `@src.file` is resolved at compile time. However,
it appears that the build runner does not change current working
directory in between compilation and execution, so it is probably safe
to calculate `sdkPath` using runtime current working directory.

Still, this requires major changes with how `sdkPath` works, since
runtime computation and allocations are required. So pretty much
anything that relied on `sdkPath` being comptime-known has been
refactored in this commit.

The most severe result of this is that, for example, `gpu.pkg` can no
longer be a comptime-known constant: it has to be a runtime function
that takes a `*Builder` and returns a `Pkg`.

This commit deals with usages of `*.pkg` and `sdkPath` within Mach
itself, but projects that depend on Mach such as `mach-examples` will
almost certainly require changes as well.

* all: update README to reflect change in pkg usage

For details on updating your code to use this version, see: 88b1106953

Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
Co-authored-by: Stephen Gutekanst <stephen@hexops.com>
2023-01-02 01:23:46 -07:00
Aaron Winter
f5d9b1ee57
ecs: store column values as independent arrays (#642)
* get column values from separate functions
* split ArchetypeStorage.block into blocks per component type
* ecs: remove allocator field from ArchetypeStorage
* ecs: remove whitespace
* ecs: correct suspicious index operation in setRow
* add back zero-size ColumnType check; bring back reliance on component names
* ecs: validate setRaw length matches
* ecs: fix failing test & move values slice into Column type

Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
Co-authored-by: Stephen Gutekanst <stephen@hexops.com>
2023-01-02 00:54:10 -07:00
Benjaaaa
052d3a7da8
mach: fix compiler error regarding zig changes (#645) 2022-12-25 13:19:48 -07:00
Aaron Winter
8aa2c97079
ecs: improve formatting (#643) 2022-12-18 03:21:11 -07:00
Aaron Winter
72ef60c8c2
ecs: fix segfault in Entities.deinit (#629)
Co-authored-by: Aaron Winter <wintera@Aarons-MacBook-Pro.local>
2022-11-26 20:53:44 -07:00
Aaron Winter
a06ac6356d
ecs: rename sort function to be camelCase (#628)
Co-authored-by: Aaron Winter <wintera@Aarons-MacBook-Pro.local>
2022-11-26 20:42:15 -07:00
Stephen Gutekanst
dad8757d3a ecs: remove stage1 compiler bug workaround
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
2022-10-15 07:55:15 -07:00
Ali Chraghi
82e10f4f28
all: build: thisDir improvements (#570)
* build:all: thisDir improvements

more performant output, usage code reducement and compileError for wrong usage

* glfw: update deprecated code
2022-09-29 08:41:46 -07:00
Ali Chraghi
fcb82345d4
all: build: organize build files and reduce unreachables (#567) 2022-09-25 10:02:51 -07:00
locriacyber
b8c48d6321
all: remove ineffective _ = variable assignments (#530)
Lastest Zig complains about this, so they must removed to build.
2022-09-14 09:42:29 -07:00
Stephen Gutekanst
8113ca370d all: remove support for stage1
With almost all tests/examples working on all platforms now with the new compiler,
https://github.com/hexops/mach/issues/180, it's time to remove stage1 support.

Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
2022-09-10 00:09:30 -07:00
Stephen Gutekanst
f1ae31ae86 ecs: improve compatibility with self-hosted compiler
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
2022-09-09 21:23:51 -07:00
Stephen Gutekanst
0a1ff43ce5 ecs: improve compatibility with self-hosted compiler
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
2022-09-08 10:22:11 -07:00
Stephen Gutekanst
54719c2de8 ecs: improve compatibility with self-hosted compiler
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
2022-09-08 07:26:15 -07:00
Stephen Gutekanst
e5a7b85e26 ecs: update self-hosted compiler TODO 2022-08-29 05:59:52 -07:00
Ali Chraghi
9f40516841 ecs:build: use stage1 for tests 2022-08-29 05:59:52 -07:00
Stephen Gutekanst
3011ed0ea4 all: update pull request template to reflect new libs/ dir
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
2022-08-26 15:12:04 -07:00
Stephen Gutekanst
0645429df9 all: move standalone libraries to libs/ subdirectory
The root dir of our repository has grown quite a lot the past few months.

I'd like to make it more clear where the bulk of the engine lives (`src/`) and
also make it more clear which Mach libraries are consumable as standalone projects.

As for the name of this directory, `libs` was my first choice but there's a bit of
a convention of that being external libraries in Zig projects _today_, while these
are libraries maintained as part of Mach in this repository - not external ones.

We will name this directory `libs`, and if we have a need for external libraries
we will use `external` or `deps` for that directory name. I considered other names
such as `components`, `systems`, `modules` (which are bad as they overlap with
major ECS / engine concepts), and it seems likely the official Zig package manager
will break the convention of using a `libs` dir anyway.

Performed via:

```sh
mkdir libs/
git mv freetype libs/
git mv basisu libs/
git mv gamemode libs/
git mv glfw libs/
git mv gpu libs/
git mv gpu-dawn libs/
git mv sysaudio libs/
git mv sysjs libs/
git mv ecs libs/
```

git-subtree-dir: glfw
git-subtree-mainline: 0d5b853443
git-subtree-split: 572d1144f11b353abdb64fff828b25a4f0fbb7ca

Signed-off-by: Stephen Gutekanst <stephen@hexops.com>

git mv ecs libs/

Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
2022-08-26 15:12:04 -07:00