I just wanted to showcase one of my side projects
i basically wanted to use zig to work with sdl3 without having to talk to c code.
which lead to me building this project.
the project is here:
note: will probably move the repo to codeberg soon
11 Likes
I have no experience at all with SDL, but what I saw until now was an incredible mess of importing c-code, consts etc.
So I must say: I love this extremely clean approach!
3 Likes
i appreciate you. this means alot to me.
im also working on vulkan bindings without the c mess, it’s not done but its getting there
1 Like
Pure Zig bindings for SDL3 without
@cImport
Are there downsides to @cImport?
There’s also https://github.com/zig-gamedev/zsdl, but they wrapped sdl’s api to be more Zig aligned. Your approach is interesting. When I was using C SDL in Zig, creating thin C wrappers made sense. But I would not want to copy-paste or even write again and again those wrappers in my next SDL project.
If you already listing all possible enums, does it make sense to wrap them into Zig enum?
i dont think there’s a clear downside. its more of a prefernce.
to be honest i was just experimenting to see how far this approach would take me, i wanted to know if taking c out of the equation will get me the same results.
yeah it doesnt really make sense to wrap them in zig enums but i just wanted to try out this approach
The downsides of cImport / translate-c is that it does not understand enough context like what’s nullable pointer and what isn’t. The new external translate-c is better in regards that it can strip away SDL_ namespace, put functions as methods inside opaque’s and struct’s! I also expect it to understand pointer nullability in future, but that requires the C codebase to actually use those attributes.
4 Likes
I’ve been working on a demo engine/realtime renderer using SDL3 (thanks @castholm for maintaining the build system package), and it has been a joy compared to my problems with the (then immature) sdl3-crate in the Rust ecosystem, and it’s escape hatch, sdl3-sys. Not to cast any shade on those projects, making good high level Rust binding takes time, but my point is that using the C library directly in Zig is very easy compared to what I had to do when my project was still Rust-based!
2 Likes
thank you for the info. the only downsides i knew about cImports were header complexity and the pointer context like you said which i didnt think were clear downsides because they were easy to fix. these were the main reasons i didnt like having to set it up every time.
Just from a glance it feels like this is mostly AI generated code, which is a shame (afaik posting it is against the Ziggit AI policy too). Your other repositories would back this up, quite a few sus markdown files to guide AI.
Luckily there is no shortage of well maintained SDL3 bindings, like as previously mentioned GitHub - castholm/SDL: SDL ported to the Zig build system.
I’ve also seen 7Games/zig-sdl3: Zig wrapper for SDL3. - Codeberg.org which looks very promising, a lot of thought and love going into zigifying the codebase.
1 Like
the doccumentation is ai. the commit messages ai. the comments ai. most of code(~75%) is not ai generated
Welcome, felixuxx. I had a knee-jerk reaction to your post which I will share below, but don’t take it the wrong way. Thanks for sharing your work with us.
pure zig
It’s a bit weird to see “pure zig” and then it’s just bindings to some C code. IMO you should say “high quality Zig bindings to SDL3”. On the other hand, “pure zig” sounds like you created a competitor to SDL3 in Zig.
unmixed with any other matter
You’ve mixed C and Zig. Impure! Words have meanings. Pure Zig means no C in the executable.
16 Likes
noted. ill keep that in mind. thank you for correcting me.
2 Likes