I finally finished a level for my Zig-powered game. Have a look:
Also, just yesterday I finished a video about my Zig gamedev experience so far. People keep asking me about it so now I have something to point at:
I finally finished a level for my Zig-powered game. Have a look:
Also, just yesterday I finished a video about my Zig gamedev experience so far. People keep asking me about it so now I have something to point at:
I started using libcurl for tests in my http backend framework (it’s funny how now it feels like everyone has their own)
next, I want to get familiar with the Zig compiler so insha’Allah I might start helping with the development. so I might use @prokoprandacek research paper.
btw, I almost got Zig to the ministry (I was just an intern so I didn’t want someone to have to deal with my codebase after I leave, and didn’t want to take responsibility for code I won’t be able to maintain) so stay tune for I might have some weird/funny news
A friend and I are collaborating on implementing the Willow Protocol in zig.
We started with an implementation of the bab hash function (which is similar to Blake3/bao). My friend found some bugs in the reference rust implementation and she helped fix things upstream; we also got a shoutout from the upstream devs on their blog. She’s focused on implementing some of the neat verifiable streaming features and merkle-tree caching of bab and I’ve moved on to the data model, focused on dealing with Paths right now.
Willow paths have no delimiters, the natural way to represent them in zig would be []const []const u8 which makes pooling/interning them a bit funny, especially since I need to support efficiently checking if a path is a prefix of another. In the process I’ve also been learning more about fuzzing in zig.
We’ve decided on maybe making a peer-to-peer event sharing/calendar app to drive development, and by coincidence I just happened to learn that partiful is sus which has me a bit more amped to make progress.
Nice. I recently played around with an esp32c6 and ended up with a similar api.
My implementation is slightly different.
const UpdateStruct = blk: {
const fields = @typeInfo(T).@"struct".fields;
var types: [fields.len]type = undefined;
var names: [fields.len][]const u8 = undefined;
var attrs: [fields.len]std.builtin.Type.StructField.Attributes = undefined;
var i = 0;
for (fields) |field| {
if (field.type == Reserved(@bitSizeOf(field.type))) continue;
types[i] = ?field.type;
names[i] = field.name;
attrs[i] = .{ .default_value_ptr = &@as(?field.type, null) };
i += 1;
}
break :blk @Struct(.auto, null, names[0..i], types[0..i], attrs[0..i]);
};
pub inline fn update(reg: @This(), fields: UpdateStruct) void {
var a = reg.read();
inline for (comptime std.meta.fieldNames(UpdateStruct)) |name| {
if (@field(fields, name)) |value| @field(a, name) = value;
}
reg.write(a);
}
I was curious whether explicitly constructing the mask as you did would lead to better codegen, so I changed my implementation.
As I was surprised to find out, for limited examples, this led to slightly more instructions for my limited examples.
After some tweaking, I ended up with the following implementation, which produced exactly the same assembly as my original implementation.
pub inline fn update(reg: @This(), fields: UpdateStruct) void {
const orig_mask: Raw, const new_data: Raw = D: {
var mask: Mask = @bitCast(~@as(Raw, 0));
var t: T = @bitCast(@as(Raw, 0));
inline for (comptime std.meta.fieldNames(@TypeOf(fields))) |name| {
if (@field(fields, name)) |v| {
@field(t, name) = v;
@field(mask, name) = 0;
}
}
break :D .{ @bitCast(mask), @bitCast(t) };
};
var raw: Raw = @bitCast(reg.read());
raw &= orig_mask;
raw |= new_data;
reg.write(@bitCast(raw));
}
Good luck in convincing your colleagues
. I also found zig to be a joy to use for embedded.
I just started learning Zig these past couple of weeks, and I have to say reading how interfaces are done in the standard library is quite interesting. But that aside, I managed to make a toy layout with the help of Raylib, inspired by HTML’s flexbox. For now it has orientation, gap, padding, min/max height and width.
I’ve gone ahead and uploaded what I’ve got https://codeberg.org/jmstevers/zig-vulkan-tutorial. I should really say thank you to @andrewrk because I have in fact copied large portions of zig-vulkan-triangle (before it was updated and posted here) and daw so thank you for those resources and the time you’ve put into them.
Nice thanks for taking the time to make this video! I got about halfway through it last night before bed. So far it looks like the main points have to do with being stuck with LLVM on Windows, both in terms of compilation speed and debug info quality. Keep an eye on @kcbanner’s latest work, he made huge strides forward in these past weeks. I believe he’s cooking up a devlog right now.
I started doing a daily Advent of (Zig) Code to get the blood flowing towards the potential development of a game engine. Wouldn’t be the first one and wouldn’t be the last one, but instead of focusing on gameplay I’d like to develop an editor, since everyone is doing engines without one for some reason.
I think the idea of having a UI/layout renderer that can be used for game-engine editors and in-game UI alike (kinda like Unity’s UI Toolkit, or Unreal’s Slate based UserWidgets) would be incredibly cool and could help many engine devs to interact with their engines easier.
And no, ImGUI is too limited and it’s data lives inside the code. I want something more portable and customizable (and pretty).
I love this idea!! the Godot app being a Godot game vibes.
Working on a reusable 2D game engine and live development environment. Might be ready for Steam’s September Next Fest.
I’m using the Clay Layout Library, and it really helped out with my editor. If you haven’t seen it it basically works like what CSS does, but in a simplified way. I’m using this wrapper: GitHub - johan0A/clay-zig-bindings: Zig bindings for the library clay: A high performance UI layout library in C. · GitHub
Thanks for checking out the video! I tried to strike a balance between highlighting my favorite things about zig and providing some useful feedback.
Glad to hear that Windows support is being worked on. Faster build times especially would transform my hot-reload-enabled workflow to a whole other level.
I’m writing a master’s thesis about implementing and comparing GPU blur filter techniques on low-end hardware such as Raspberry Pis. Zig is featured too!
GenAI disclaimer: I’m using an LLM to review my drafts and support my thesis’s language. This is permitted by the uni. Personally I have mixed feelings about this, as it might cause my brain’s writing ability to actually regress instead of improving, but having an on-demand writing partner is just too enticing to pass up.
I’ve been creating zig-python-sdist, a zig package to create python source distributions that build cpython extensions upon installation directly with zig build . It handles linking the cpython headers, generating the necessary metadata and bundling dependencies for you, so the pypi package only depends on the ziglang and setuptools package to build the wheel on the target system
I’ve been working on a Zig interpreter written in OCaml. It was a really educational project for me, as I discovered every single edge case of Zig that way. I started with a simple version that conflates comptime and runtime, essentially turning Zig into a Python-like scripting language, but that turned out to be too slow, even with comptime memoization, because Zig stdlib really depends on comptime extesively and if it’s not folded, just the memoization is extremely costly. However, despite being slow, it was able to run the Zig compiler. The next version separated the step for comptime execution, which of course brings the need to encode all the comptime semantics that Zig compiler does, then lowers the result into a high-level IR that can be evaluated at runtime. I still have some differences between how I deal with comptime memory vs how Zig compiler does it, so it’s not 100% functional and I’m not sure if I ever get to finishing it. Nonetheless, it made me appreciate the complexity of the Zig language and how simple it feels despite the complexity existing in the background.
Still pottering with my Zig microkernel/OS for the PinePhone. Pacman running smoothly, but still no sound. It has been a great way to learn Zig (and Arm global assembly).
But now back to part-time only, since I’m working with some LoRa/ZigBee gadgets that involved switching back to TinyGo. I have a software bridge now running on a PI + ConBeeII that can send ZigBee sensor messages ~3km
But this month I’m busy searching a new home away from the ever increasing heat in southern Europe.
previous post:
Once again it is great fun to read what others are working on, you all put me to shame! well done ![]()
Since doing the Zig Native Messaging host with help from folks here (since y’all don’t like anything labeled “AI” or “LLM”) Porting handwritten JavaScript to Zig: Native Messaging host - #19 by TerenceTux, GitHub - guest271314/native-messaging-zig: Zig Native Messaging host · GitHub, I’ve been working on AOT JavaScript to WASM GC with js2wasm GitHub - loopdive/js2: ECMAScript to WebAssembly GC AOT compiler · GitHub, GitHub - guest271314/native-messaging-js2wasm: js2wasm Native Messaging host · GitHub; testing ComponentizeJS, jco, componentize-qjs GitHub - guest271314/native-messaging-componentize-js: ComponentizeJS Native Messaging host · GitHub, GitHub - guest271314/native-messaging-componentize-qjs: componentize-qjs Native Messaging host · GitHub; compiling QuickJS NG to WASM with WASI support, with my JavaScript pre-embedded, and optimizing that output for size How to optimize WASM build · quickjs-ng/quickjs · Discussion #1546 · GitHub; compiling Bellard and Gordon’s Micro QuickJS to WASM, same as above, with JavaScript -re-embedded, and optimizing WASM binary for size (down to around 239.5 KiB right now, still W.I.P.); implementing a Native Messaging host in D, with WASM and WASI support (still testing, unpublished, though I’ll probably throw on the GitHub (more non-Zig domain) sometime this week); revisting non-containerized live media streaming and static playback re a new IETF proposal for a “container” for WebCodecs involved media draft-ietf-moq-loc-02 - Low Overhead Media Container - kinda the opposite of why WebCodecs came about API for containers? · Issue #24 · w3c/webcodecs · GitHub, in conjunction with my implementation of stacking media produced by WebCodecs into a blob WebCodecsOpusRecorder/WebCodecsOpusRecorder.js at main · guest271314/WebCodecsOpusRecorder · GitHub, with separate indexing to track offsets, and thinking about how to even do that without offsets, more too thinking about exactly what a media “container” is and isn’t - per some consensus, 'cause a codec itself could be considered a media container.
Getting banned from Bytecode Alliance Banned from Bytecode Alliance Zulip (and banning you from engaging in our GitHub repos going forward) · Issue #46 · guest271314/banned · GitHub for daring to scrutinize the technical issues with using StarlingMonkey for the WebAssembly Component Model implementations where the base WASM binary spit out is around 13.4 MiB! Whereas QuickJS can be used to produce a WASM binary under 1 MiB. Thus my independent experiments with QuickJS NG and Micro QuickJS to get that size down further.
A lot of hand digging for some concrete footing and eventual 10 foot plus walls at a French/Victorian type chateau stylee job. Searing in my brain you HAVE to put some steel on it when it’s a sand finish. More hand digging at other jobs for sidewalks and stuff.
Thinking about JavaScript source static analysis to determine exactly what is necessary to complete the instruction using a given engine, and extracting ONLY that source code to build custom engines/runtimes.
Etc.