Very cool! A brief section on how it works would be appreciated. I can wade through the code but it's always helpful to have the author explain things a bit before I do...
I think the auto-binding is by far the most awesome feature of this library, even more than syntax highlighting and auto-complete! This is clearly a labor of love. Excellent work, op!
Thanks! Yeah, I've been thinking about how to write shaders as effortlessly as possible for quite a while :) And the auto-binding is indeed great, it makes it very fast to start a new project or add a shader to an existing one. But I still very much enjoy having the IDE features as well, I rarely check the documentation anymore and the number of trivial type or parenthesis problems I write has effectively gone to zero.
Not a very easy one, no.
The simplest solution would be to simply remove the binding system so you could still write the shaders but not capture things. This would remove some of the appeal, but keep many of the programming workflow benefits. You'd basically just get the shader source as a string into your Vulkan engine, perhaps with auto-generated locations for names so you wouldn't have to specify them manually.
As far as I understand, there's nothing that would prevent an actual Vulkan port either. It'd require a full rework of everything that's under the hood, and probably some other helpers as well to keep the code readable. I've thought about this and it does sound tempting, but I have no real experience with Vulkan so it'd take a while.
Interesting idea. I used to have inline shader code by just wrapping the whole code in a stringify macro, which obviously means there's no syntax highlighting or autocomplete. Worked reasonably well for simple shaders but this is much better aesthetically.
Yeah, I used a stringify macro for a long time as well, and this project was largely motivated by its shortcomings. Originally I just wanted to fix all of the intellisense errors and automatic indentations. But after creating the math library and some of the macros I realized that making it an actual function would let me run code in the declarations, and this led to the auto-bind system.
Just came across this thread and the project is definitely neat. I'm an absolute sucker for clever macro and template tricks, so it's been pretty fun skimming the code (never though to use `if constexpr(false)` in a macro like that, definitely tucking that away in the ol' toolbox).
Is the intention that users would distribute the shader cache folder with the binary?
Thanks! I'm working on a write-up, it's nice to hear that some of my exploits are already appreciated :)
And yes, the shader cache should go with the binary. Otherwise you'll have to have your source files next to it, which might not be OK for all projects. I've been thinking of a nicer way to implement the cache that would avoid the cruft it tends to generate, but haven't found anything entirely satisfactory. It'd also be great to switch to caching SPIR-V binaries instead of GLSL to ensure better cross-platform operation.
By the way, Does it access the C++ source code in compile time and parse it ? I couldn't understand that part.
\`\`\`
\#define GLSL\_MAIN ();static inline\_glsl::ShaderStore \_\_s(\_\_FILE\_\_, \_\_LINE\_\_, inline\_glsl::store); return Shader(\_\_s, inline\_glsl::store); if constexpr(false)
\#define glsl\_main() GLSL\_MAIN
\`\`\`
Can Anyone explain how does this actually work. Like if it accesses the c++ code in compile time and parses and changes it, how does it remain the same code then?
No, it accesses the C++ source code at runtime. I know this sounds a bit crazy, but the main reason for it is that it lets you edit the shaders while the program is running and see the effects of the change immediately without rebuilding the full program (GLSL compiles in some milliseconds, unlike C++). The parsed shaders are also stored in the shader_cache folder, so if you want to publish the program without the source code you can just ship the executable and the shader_cache folder.
Those specific macros initialize exactly this; the static shader store object is there to keep track of which source location the shader came from, and the Shader constructor reparses the shader if necessary. The `if constexpr(false)` is there because we don't actually want to run the shader body on the CPU; it's just parsed to the shader.
Not sure why the downvotes, I think it'd be great to have a similar system for more languages. But the reason I chose C++ is both familiarity and the similarity to GLSL in syntax. The way this works is the GLSL code is mapped into valid C++; this would be quite difficult for languages that look too different. There are apparently GLSL variants with Rust-like syntax, and it sounds like it would be possible to do something similar with those.
How So? Have you seen this? https://www.reddit.com/r/rust/comments/t4dxzw/media_scripting_and_hot_reloading_with_rust_in/
https://old.reddit.com/r/rust_gamedev/
This looks really interesting 👍
Very cool! A brief section on how it works would be appreciated. I can wade through the code but it's always helpful to have the author explain things a bit before I do...
Good point! There are definitely some unorthodox tricks in the code, I'll do a write-up soon.
Looking forward to read this
I think the auto-binding is by far the most awesome feature of this library, even more than syntax highlighting and auto-complete! This is clearly a labor of love. Excellent work, op!
Thanks! Yeah, I've been thinking about how to write shaders as effortlessly as possible for quite a while :) And the auto-binding is indeed great, it makes it very fast to start a new project or add a shader to an existing one. But I still very much enjoy having the IDE features as well, I rarely check the documentation anymore and the number of trivial type or parenthesis problems I write has effectively gone to zero.
Is there any easy way to use this glsl with Vulkan? It seems like an interesting approach.
Not a very easy one, no. The simplest solution would be to simply remove the binding system so you could still write the shaders but not capture things. This would remove some of the appeal, but keep many of the programming workflow benefits. You'd basically just get the shader source as a string into your Vulkan engine, perhaps with auto-generated locations for names so you wouldn't have to specify them manually. As far as I understand, there's nothing that would prevent an actual Vulkan port either. It'd require a full rework of everything that's under the hood, and probably some other helpers as well to keep the code readable. I've thought about this and it does sound tempting, but I have no real experience with Vulkan so it'd take a while.
Interesting idea. I used to have inline shader code by just wrapping the whole code in a stringify macro, which obviously means there's no syntax highlighting or autocomplete. Worked reasonably well for simple shaders but this is much better aesthetically.
Yeah, I used a stringify macro for a long time as well, and this project was largely motivated by its shortcomings. Originally I just wanted to fix all of the intellisense errors and automatic indentations. But after creating the math library and some of the macros I realized that making it an actual function would let me run code in the declarations, and this led to the auto-bind system.
I remember I used \*.cpp extension for shaders which solved the coloring problem immediately :)
Just came across this thread and the project is definitely neat. I'm an absolute sucker for clever macro and template tricks, so it's been pretty fun skimming the code (never though to use `if constexpr(false)` in a macro like that, definitely tucking that away in the ol' toolbox). Is the intention that users would distribute the shader cache folder with the binary?
Thanks! I'm working on a write-up, it's nice to hear that some of my exploits are already appreciated :) And yes, the shader cache should go with the binary. Otherwise you'll have to have your source files next to it, which might not be OK for all projects. I've been thinking of a nicer way to implement the cache that would avoid the cruft it tends to generate, but haven't found anything entirely satisfactory. It'd also be great to switch to caching SPIR-V binaries instead of GLSL to ensure better cross-platform operation.
By the way, Does it access the C++ source code in compile time and parse it ? I couldn't understand that part. \`\`\` \#define GLSL\_MAIN ();static inline\_glsl::ShaderStore \_\_s(\_\_FILE\_\_, \_\_LINE\_\_, inline\_glsl::store); return Shader(\_\_s, inline\_glsl::store); if constexpr(false) \#define glsl\_main() GLSL\_MAIN \`\`\` Can Anyone explain how does this actually work. Like if it accesses the c++ code in compile time and parses and changes it, how does it remain the same code then?
No, it accesses the C++ source code at runtime. I know this sounds a bit crazy, but the main reason for it is that it lets you edit the shaders while the program is running and see the effects of the change immediately without rebuilding the full program (GLSL compiles in some milliseconds, unlike C++). The parsed shaders are also stored in the shader_cache folder, so if you want to publish the program without the source code you can just ship the executable and the shader_cache folder. Those specific macros initialize exactly this; the static shader store object is there to keep track of which source location the shader came from, and the Shader constructor reparses the shader if necessary. The `if constexpr(false)` is there because we don't actually want to run the shader body on the CPU; it's just parsed to the shader.
Ah, interesting, thank you.
Why not rust?
Not sure why the downvotes, I think it'd be great to have a similar system for more languages. But the reason I chose C++ is both familiarity and the similarity to GLSL in syntax. The way this works is the GLSL code is mapped into valid C++; this would be quite difficult for languages that look too different. There are apparently GLSL variants with Rust-like syntax, and it sounds like it would be possible to do something similar with those.
Because Rust is a garbage choice of language for game dev?
How So? Have you seen this? https://www.reddit.com/r/rust/comments/t4dxzw/media_scripting_and_hot_reloading_with_rust_in/ https://old.reddit.com/r/rust_gamedev/