I think a simple solution would be to just write out a picture for every animation frame and then you could use ffmpeg to stitch those together into a gif.
Raylib also has a gif example raylib example screen recording but that uses this small single header c library raylib/examples/core/msf_gif.h at 10a889c482bc001533536162cc2cc9d193845eae · raysan5/raylib · GitHub
I’m working on a controller for a custom PVD (Physical Vapor Deposition) setup do Thin Film Deposition processes in a lab 
The zig part of the program is tasked with talking to the hardware, exposing an interface over SCPI and ensuring guarantees like interlocks, maximum running hours for each device, ect.
Zig really turned out to be the perfect solution for this task - python doesn’t have many hardware vendor libraries, and thanks to zig’s excellent C interop i can use battle tested libraries like libscpi or nanomodbus. Additionally thanks to the new IO interface it is trivial to write tests for the hardware communication (as it is abstracted over Io.File). io.concurrent and Io.Queue make splitting each piece of hardware code into its own task very easy, while tagged unions are great at expressing the FSMs that are at the core of each device. The program also does zero allocations after startup!
live and shared
Not much, but removing ‘async’, is HUGE!
ZIX;
Zero sIX; 06;
A surgical backend library/engine with a wiring tools.
An investment for the next 5+ years for my backend network.
Currently working on implementing a board game in zig + godot. I originally had the backend built in rust with websockets and protobufs. However, I lost the plot and am simplifying the design. Unfortunately don’t have anything flashy to show yet. But here is a screenshot from the Godot client, no backend is hooked up, so players are not showing up on eachothers view.
I have been using Zig both at work (as a developer/meteorologist) and at home for some side projects!
At work, I wrote a binary format decoder for meteorological data. The BUFR format is heavily templated, and I was able to use Zig’s comptime and reflection to handle the decoding of template metadata in a neat way. I also used Zig to write a build-time step that reads the WMO BUFR tables and converts them to valid Zig code. At the time I wasn’t aware of ZON, so in the future I plan to migrate that direction.
For reference, most BUFR decoding libraries are still in FORTRAN. There is a pure python library, but naturally, it’s slow. I don’t have a public repo for it yet but I am using my Zig BUFR decoder to do client-side data decoding in the browser via WASM. It was a challenging but enlightening project.
For a side project, I’ve been working on building a WASM-freestanding interface to the zfp compression codec. The zfp algorithm/codec is designed for 1D-4D contiguous arrays from simulation data, and can operate in fixed-rate, fixed-precision, or fixed-accuracy modes. It’s really great for meteorological data because you can enforce a maximum error bound on a field, and since it compresses in spatial blocks, is really good at preserving gradients in the data.
I want to be able to send and receive 2D/3D weather forecast data in a nice compressed format, making data transfer and storage much nicer. The goal is to be able to read a compressed array over the network and decompress it client side in the browser via the freestanding WASM wrapper library. The WASM wrapper work is very much in progress, but the zfp C-library build step/wrapper for Zig (and freestanding libc shims) are fully functional..
I have plans to use Zig for plenty more meteorological projects, but this is where I’ve started! Fun to see what everyone is working on here.
Weaponizing my annoyance with NixOS’s laxness wrt duplicate packages × my tiny SSD to dig down and do my best to reduce the number of different versions of the same package being present in one’s system.
Currently working on an immediate TUI backed by termbox2. It was supposed to be a demo using termbox2, but I started to do more and more things and I decided to make it a now a library.
Progress is slow but I’m learning a lot about utf-8 code points, layouting, layers and how to design a good API and of course, zig! The main point is to be juicy to human eyes read and editing should be simple without losing extensibility.
off-topic to this thread, but the proposal of nix flakes is precisely that each one carries its own closure. they are not duplicates. the symbolic name is secondary to the hash. this wasn’t the case with nix channels and was one of the reasons flakes were invented.
Yes, of course. Unfortunately, doesn’t stop me from being annoyed when I count the icu4cs and the glibcs on this machine.
Because I do work a lot with S3 object storage systems at my job, I’m working on a CLI client for the Zig S3 client library z3 for which I’m a co-maintainer.
Since the S3 API is rather complex and many API calls are not needed very often, for now, the CLI will cover only some basic functionalities which I use at a daily base. However, its still a lot of work because the CLI needs enhanced argument parsing due to the many parameters even a default S3 call needs. Nevertheless, its really fun designing and building such a complex CLI tool!
Is it as difficult at zig itself? Especially the stuff passed on the LLVM causes zig cc to have over 1000 options.
I use my custom CLI arg parser/lexer for processing the args. As always, parsing args is kind of boilerplate code, but its very straightforward and efficient.
Currently working on porting and upgrading an embedded time series database to Zig
Writing it in C was kinda miserable and Zig includes a dozen target independent things that make my life easier.
That sounds fun! Are you planning on open sourcing it at all?
Something I would use ^_^
Because I realy much fell in love with zig’s comptime, I decided to write a command line argument parser inspired by the clap crate in Rust.
You can define a struct and just let the parser populate it’s fields:
const CliApp = struct {
arg: []const u8,
flag: bool,
_file: []const u8,
};
...
pub fn main(init: std.process.Init.Minimal) !void {
const alloc = std.heap.smp_allocator;
const args = zap.parse(CliApp, init.args, alloc);
// Prints to stderr, unbuffered, ignoring potential errors.
std.debug.print("CliApp: Args are {any}.\n", .{args});
}
Then run it:
cliapp --arg text --flag file1
The project is hosted on github:
zap
Im currently working on a Vietnamese IME Engine. Had done all the tricky part, now i just need to test it in terminal and bind it to fcitx5
Here is my project: hydrangea
finally started learning zig about a month ago after becoming unemployed
since my background is mostly web, decided to build an http server to maybe power some future projects
tried to do most I could do at comptime, and it was a lot of fun