a1fe671db8
* 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:
|
||
|---|---|---|
| .github | ||
| dev | ||
| doc | ||
| libmach | ||
| libs | ||
| shaderexp | ||
| src | ||
| tools | ||
| .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 --recursive https://github.com/hexops/mach-examples
cd mach-examples/
zig build run-boids
Cross-platform graphics, a unified shader language & compute shaders.
(Requires zig 0.11.x | known issues)
Get started with 15+ examples
- Examples showcase: https://machengine.org/gpu/
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-freetype: Ziggified Freetype 2 & HarfBuzz bindings
- 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
Join the community
- #hexops:matrix.org Matrix chat and Discord server, come discuss the future of game engines & graphics in Zig!
- machengine.org
- 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 join the Matrix chat and say hi!
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.
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 works with the new self-hosted Zig compiler only. This means you'll need to use the latest Zig nightly version.
Currently we test using 0.11.0-dev.1023+1c711b0a6. Newer is generally better, but you can download this version here:
- linux-x86_64: https://ziglang.org/builds/zig-linux-x86_64-0.11.0-dev.1023+1c711b0a6.tar.xz)
- windows-x86_64: https://ziglang.org/builds/zig-windows-x86_64-0.11.0-dev.1023+1c711b0a6.zip
- macos-x86_64 (Intel): https://ziglang.org/builds/zig-macos-x86_64-0.11.0-dev.1023+1c711b0a6.tar.xz
- macos-aarch64 (Apple Silicon): https://ziglang.org/builds/zig-macos-aarch64-0.11.0-dev.1023+1c711b0a6.tar.xz
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 libs/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, 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!