Closed Interrupt closed 1 month ago
Thanks! Yeah, not supporting --reflection
is more or less an oversight.
The second one is a bit more tricky though, since there may be multiple shaders in the same .glsl file, and each generates its own getShaderDesc()
function.
The solution is probably to add a nested per-shader namespace:
// per-shader namespace struct
pub const Bla = struct {
pub fn shaderDesc(backend: sg.Backend) sg.ShaderDesc { ... }
}
...that way it should be possible to walk the imported toplevel struct and find all shaders (== nested namespace-structs) and their getShaderDesc() functions.
I wonder if the whole shader-reflection stuff could also be simplified when taking Zig's comptime features into account... e.g. instead of having runtime functions to query the reflection information just add constants to the per-shader-namespace struct which can then be discovered by inspecting the struct via Zig's comptime type reflection (or maybe both makes sense).
So far the language binding backends in sokol-shdc are more or less copies of the C backend. But it might be worth supporting language-specific features a bit more.
Having a per-shader namespace like that would help out a lot - that would make it way more usable from a Zig point of view.
As for the reflection, I think you're right in that adding constants to that namespace also makes a lot of sense.
Closing this now as completed via https://github.com/floooh/sokol-tools/pull/147 (thanks!).
If we want to change the way reflection works in the Zig codegen we should do this via new issues.
Two notes about using the Zig target for
sokol-shdc
when making a Material system:--reflection
argument - I'm not seeing any extra data get baked into the .zig output file.pub fn getShaderDesc(backend: sg.Backend) sg.ShaderDesc { ...
to work better with Zig reflection when making a Material system.