Hello,
I am fairly new to graphics programming and there are a lot of APIs with a lot of zig libraries for them, so I wanted to ask if there are any that someone has had a good experience with. I am intending to use it with Zig 0.16.0.
Hello,
I am fairly new to graphics programming and there are a lot of APIs with a lot of zig libraries for them, so I wanted to ask if there are any that someone has had a good experience with. I am intending to use it with Zig 0.16.0.
zgl has served me well for openGL, and vulkan-zig for VK.
Any specific things youâre looking for in a wrapper other than type safety?
Can vouch for vulkan-zig too, learning Vulkan at the moment and Iâve had a great experience with the Vulkan API being ziggified. You are still gonna have to get your hands dirty in C style stuff for something like VMA, but I suppose a light wrapper could help.
Other than that, sokolâs zig bindings were great to work with too last time I used them
I can vouch that zokolâs zig bindings are great
For anyone learning vulkan-zig, this is the best book Iâve found on it. It uses Zig bindings whenever possible, which I havenât seen in other tutorials. Itâs still a WIP but it already has a significant amount of content.
I am very new to GPU Programming, so really just something that allows me to forget that there is c somewhere below the API and has proven to work well so I know that my mistakes are truly mine.
One minor thing Iâve run into with the zig and vulkan is trying to cast from *T to [*]T.
They donât coerce, which is very good, but using @ptrCast to cast them feels like overkill, since if you change the type from T to U, zig will still cast *U to [*]T.
This comes up in the various Vulkan Info types that take a list of items (like semaphores or fences), but luckily the validation layer will catch it. Be sure to @panic on validation errors!!!
Take a look at this part of the Zig documentation: Documentation - The Zig Programming Language.
const single: *const i32 = &0;
const many: [*]const i32 = single[0..1];
I prefer to just create an array and reference that.
Oh! Thatâs perfect, thank you
Tbf, type-safety on top of what a 3D-API C-API provides wonât help you figure out why youâre staring at a black screen instead of a hello-world-triangle
Pretty much all problems in 3D rendering can only be caught at runtime. What you rather want is a validation layer in the 3D API (or wrapper library) which tells you whatâs wrong while running the code.
GL has nothing of that sort (at least nothing directly built in, and KHR_debug extension support isnât all that great last I checked), and Vulkan will spam you with tons of too detailed messages which will leave you more confused than without.
D3D11 and Metal are the sweet spot when it comes to helpful validation layer messages (and not to toot my own horn, but the sokol-gfx validation layer should also catch most API âmisuseâ).
Also, if possible use a 3D API debugger like RenderDoc, this is worth a thousand validation layer messages ![]()
As mentioned by others, vulkan-zig is great.
The Vulkan API is essentially a series of XML files describing what functions and types are available, vulkan-zig consumes these XML files and produces Zig code that exposes the API to you.
This is nice because you can get the benefits of Zigâs type system without having to give up working with the actual API. If you follow a tutorial for using Vulkan from C or C++, everything will work exactly the same way but with additional type safety.
If you use Windows, I believe the best API to learn and get started with is D3D11. It doesnât have many modern features, but it more than makes up for it in debug tooling, ease of use, documentation, etc etc. Probably the nicest native GPU API to this day. You could get started with Vulkan, but itâs quite painful.
If you donât mind âlayers of abstractionâ, SDL_GPU has a full Zig wrapper and itâs one of the nicest GPU APIâs Iâve used, with much larger access to modern GPU techniques (excluding bindless). It should also be wayyyy easier to learnâŚ