No description
0ef13eb1cc
In the past: * hexops/mach#156 was the initial ECS implementation detailed in https://devlog.hexops.com/2022/lets-build-ecs-part-1 * hexops/mach#157 was the second major redesign in which we: * Eliminated major limitations (e.g. inability to add/remove components at runtime) * Investigated sparse sets * Began thinking in terms of databases * Enabled runtime introspection Our second revision of the ECS, however, still had _archetypes_ exposed as a public-facing user concern. When a new component was added to an entity, say a weapon, the table storing entities of that archetype changed to effectively have a new column `?Weapon` with a null value for _all existing entities of that archetype_. We can say that our ECS had archetypes as a user-facing concern AND this made performance worse: when iterating all entities with a weapon, we needed to check if the component value was `null` or not because every column was `?Weapon` instead of a guaranteed non-null value like `Weapon`. This was a key learning that I got from [discussing ECS tradeoffs with the Bevy team](https://github.com/hexops/mach/pull/157#issuecomment-1022916117). This third revision of our ECS has some big benefits: * Entities are now just IDs proper, you can add/remove arbitrary components at runtime. * You don't have an "entity which always belongs to one archetype table which changes" * Rather, you have an "entity of one archetype" and adding a component means that entity _moves_ from one archetype table to another. * Archetypes are now an implementation detail, not something you worry about as a consumer of the API. * Performance * We benefit from the fact that we no longer need check if a component on an entity is `null` or not. * Introspection * Previously iterating the component names/values an entity had was not possible, now it is. * Querying & multi-threading * Very very early stages into this, but we now have a general plan for how querying will work and multi-threading. * Effectively, it will look much like interfacing with a database: you have a connection (we call it an adapter) and you can ask for information through that. More work to be done here. * Systems, we now have a (very) basic starting point for how systems will work. Some examples of how the API looks today: * |
||
|---|---|---|
| .github | ||
| dev | ||
| ecs | ||
| glfw | ||
| gpu | ||
| gpu-dawn | ||
| src | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmodules | ||
| build.zig | ||
| LICENSE | ||
| LICENSE-APACHE | ||
| LICENSE-MIT | ||
| README.md | ||
Learn more at hexops.com/mach
Join the conversation
Our community exists on Matrix chat, join in and help build the future of game engines & graphics in Zig!
You can also follow @machengine on Twitter for updates.
⚠️ in-development ⚠️
Under heavy development, not ready for use currently.
Supported platforms
Mach is still incredibly 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 | 🏃 | 🏃 | 🏃 | 🏃 |
- ✅ 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.)
Subrepositories / projects
Whether you're interested in using all of Mach, or just some parts of it, you get to choose. Our libraries all aim to have the same zero-fuss installation, cross compilation, and platform support:
- mach-glfw: Ziggified GLFW bindings with 100% API coverage
Contributing
Mach is maintained as a monorepo. When changed are merged to this repository, we use some git fu to pick out the commits to subdirectories and push them ot sub-repositories. For example, commits to the glfw/ directory also get pushed to the separate mach-glfw repository after being merged here.
There are only two requirements:
- Pull requests to sub-repositories must be sent to this monorepo, not to the sub-repository itself - to avoid some annoying merge conflicts that can arise.
- Individual commits may not change multiple sub-repositories at the same time (e.g. a commit to
glfw/cannot also include changes togpu/, to avoid confusion.)