' devlog2022 ends in an hour, and new opportunities open. I am filled with optimism, pessimism, fear, and excitement. A walking, talking contradiction of life at your service. Gratitude I am greatful for so much in life-I have health, a great job, family, two new nephews, kittos of my own, friends, and an incredible community of people passionate about some of the same things as me. Over this last year, almost 300 people joined the Mach engine Discord sharing in the vision of Zig game development with me.
Mach engine uses Zig as the C/C++ compiler for almost everything. Unlike other toolchains, Zig enables many more safety checks by default - such as clang’s undefined behavior sanitizer. Using Zig, we’ve caught undefined behavior in established projects like GLFW[1], the DirectX Shader Compiler[2], and more. Undefined behavior is everywhere, often relatively innocuous, and hard to catch. Professional C/C++ developers know to run UBSan fuzzers as part of their test suite, but even with that we’ve found e.
We’ve just finished a complete rewrite of mach/gpu (WebGPU/Dawn bindings for Zig), with 700+ commits, ~7.4k LOC, and 100% API coverage. WebGPU (not to be confused with WebGL) is a modern graphics API, acting as a unified API to the underlying Vulkan/Metal/DirectX APIs. Despite it’s name, it is also designed for use in native applications via its C API. Dawn is the C++ implementation of WebGPU by Google, used in Chrome, planned to be shipped to millions of browsers in the not too distant future.
As we’ve been building Mach engine, we’ve been using a neat little pattern in Zig that enables writing flag sets more nicely in Zig than in other languages. What is a flag set? We’ve been rewriting mach/gpu (WebGPU bindings for Zig) from scratch recently, so let’s take a flag set from the WebGPU C API: typedef uint32_t WGPUFlags; typedef WGPUFlags WGPUColorWriteMaskFlags; Effectively, WGPUColorWriteMaskFlags here is a 32-bit unsigned integer where you can set specific bits in it to represent whether or not to write certain colors:
In this series we build the Mach engine Entity Component System from scratch in the Zig programming language. In part one, we looked at how ECS intersects with data oriented design, starting without any foundational understanding of how ECS typically works and instead working from first-principles to arrive at what would probably be the most computationally efficient implementation. In this ~24 page part two, we examine functionality gaps our first approach had, explore how databases relate to ECS, and begin writing our actual implementation in Zig!
Five months ago we announced some of our vision for Mach & the future of graphics with Zig. Today we’ve reached Mach v0.1 with over 1,100 commits. Cross-platform graphics in 60 seconds If you have Zig v0.10 you can get started with cross-platform graphics in under 60 seconds, try it for yourself: git clone https://github.com/hexops/mach cd mach/gpu zig build run-example (not working? see known issues) All you need is zig, git, and curl.
If you just got started with Zig, you might quickly want to use a hashmap. Zig provides good defaults, with a lot of customization options. Here I will try to guide you into choosing the right hashmap type. 60-second explainer You probably want: varmy_hash_map=std.StringHashMap(V).init(allocator);Or if you do not have string keys, you can use an Auto hashmap instead: varmy_hash_map=std.AutoHashMap(K,V).init(allocator);Where K and V are your key and value data types, respectively. e.
In this multi-part series we’ll build the Entity Component System used in Mach engine in the Zig programming language from first principles (asking what an ECS is and walking through what problems it solves) all the way to writing an implementation in a low-level programming language. The only thing you need to follow along is some programming experience and a desire to learn. In this article, we’ll mostly go over the problem space, data oriented design, the things we need our ECS to solve, etc.