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> |
||
|---|---|---|
| .github | ||
| dev | ||
| doc | ||
| ecs | ||
| examples | ||
| freetype | ||
| glfw | ||
| gpu | ||
| gpu-dawn | ||
| shaderexp | ||
| src | ||
| tools | ||
| www | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmodules | ||
| build.zig | ||
| LICENSE | ||
| LICENSE-APACHE | ||
| LICENSE-MIT | ||
| README.md | ||
Mach: game engine & graphics toolkit for the future
Written in Zig, Mach is for creating games, graphical applications, and desktop/mobile apps:
- Data-driven, tooling oriented
- Composable
- Competitive with Unity and Unreal in spirit (a fully fledged editor in the future, etc.)
Cross-platform graphics in ~60 seconds
git clone https://github.com/hexops/mach
cd mach/
zig build run-example-boids
Cross-platform graphics, a unified shader language & compute shaders.
(Requires zig 0.10.x | known issues)
Join the conversation
Join us on Matrix chat in building the future of game engines & graphics in Zig!
Follow @machengine on Twitter for updates.
Contributors are very welcome! There are lots of places you can help out with little knowledge, so feel free to reach out!
Sponsor development

No, it’s not Tom from myspace - it’s me, @slimsag! It’s taken almost a year to get here - staring at broken CI pipelines, C++ compiler errors, buying hardware to test every OS+arch possible, and more.
There are few things in life that I am more serious about than this work. I dedicate ~48 hours/week to my dayjob, and ~50h/week to Zig building Mach and running zigmonthly.org. After three years of aggressively pushing for progress in this exact way, I have no plans to slow down anytime soon.
Learn more & examples: machengine.org
Supported platforms
Mach is still early stages, so far we have support for building from the following OS to the following targets:
| Building for | From macOS x86_64 | From macOS M1/aarch64 | From Linux x86_64 | From Windows x86_64 |
|---|---|---|---|---|
| macOS x86_64 | ✅ | ✅ | ✅ | ✅ |
| macOS M1/aarch64 | ✅ | ✅ | ✅ | ✅ |
| Linux x86_64 | ✅ | ✅ | ✅ | ✅ |
| Windows x86_64 | ✅ | ✅ | ✅ | ✅ |
| iOS | 🏃 | 🏃 | 🏃 | 🏃 |
| Android | 🏃 | 🏃 | 🏃 | 🏃 |
| Web (Wasm) | 🏃 | 🏃 | 🏃 | 🏃 |
- ✅ Tested and verified via CI.
- ✔️ Should work, not tested via CI yet.
- 🏃 Planned or in progress.
- ⚠️ Implemented, but has known issues (e.g. bugs in Zig.)
Supported Zig version
Mach targets Zig nightly, binary releases are available at https://ziglang.org/download
Currently tested with: 0.10.0-dev.2439+c84f5a5f9
Libraries
Mach has many libraries you can use for game development in Zig - you don't have to use the entire engine. All our libraries aim to have the same zero-fuss installation, cross compilation, and platform support:
- mach-glfw: Ziggified GLFW bindings with 100% API coverage
- mach-gpu-dawn: Google's Dawn WebGPU implementation, cross-compiled with Zig into a single static library
- mach-system-sdk: More libraries for cross-compilation with Zig
Contributing
Mach is maintained as a monorepo. When changes are merged to this repository, we use some git-fu to pick out the commits to subdirectories and push them to sub-repositories automagically. Changes to the glfw/ directory in this repository get pushed to the separate mach-glfw repository after being merged here, for example.
Please prefix commits / pull requests with the project name (glfw: fix an issue, gpu: fix an issue, examples: fix an issue, etc.) and if possible only one project per commit. If you don't know how to do this, no worries, we can help - just send your PR anyway!

