I've been working a lot with #glsl for a while now, writing complex code. Overall, I feel like the single improvement that would make the most difference for the language would be support for pass-by-reference instead of copy in/copy out syntax, as suggested here https://github.com/KhronosGroup/GLSL/issues/84
This would make it possible to do a lot of things that are either not possible or ridiculously inefficient to compile, including object oriented programming.
Made another #GLSL filter for the smartphone. It is a bit frustrating to take photos with this manipulation because Safari crashes after every shot on my smartphone. OK, it's too much for the device when you push it to the limit.
I know SPIR-V is not meant for human readability and all that, but damn. Is there not any way that the variables were named anything closer to useful than %13525? I understand that it's not a one-to-one match with my glsl variables, but like... This feels like it's actively trying to obfuscate the code 🥲
Maybe there's some glslang option I don't know about that tries to make them a bit clearer?
Learn how to change the look of the halftone pattern shader with different blend modes. View the Shadertoy demo to see it in action, and change the options.
Somehow I was under the impression that the const keyword for function parameters in #GLSL was mostly there for the benefit of programmers, so we'd get an error if we try to modify something we're not supposed to, but that the compiler would figure out if it does get modified or not on its own.
I was wrong. I have a case where just adding the const keyword to one parameter makes a shader twice as fast - from 750µs to 300µs.
Totally unexpected for me, am I the only one?
Now this is also making me doubt another frequent assumption I make. #GLSL has an "in" specifier for function parameters too, and I'm basically ignoring it most of the time because it seems to me that it's the same as not specifying anything if the parameter is not an inout. But does specifying "in" actually change anything to compilers compared to not specifying anything?
In the mathematical sense, this is is not a kaleidoscope but a conformal mapping. What they have in common with a kaleidoscope are the distortions that lead to symmetries.
(p^c-1)/(p^c+1)
This mapping (distortions of the image plane) is calculated with complex numbers. Where p are the pixel coordinates and c is a constant.
@twilliability This is roughly how one could implement this mapping in #GLSL as a fragment shader. The constants in this example are chosen somewhat arbitrarily.
The camera image comes from a USB web cam and the effect can be calculated in real time. This is a screen shot of my test / development environment.
So much to do, but can't stop watching & hacking on this pseudo fluid sim every now & then... 🤩 Probably will develop this further into a tutorial for https://thi.ng/shader-ast
I'm curious to hear if anyone has successful strategies for debugging shader compile time issues (specifically #GLSL in #Vulkan in my case but still interested in hearing about others).
I've got this shader that takes over a minute to compile. There's various things I could do to prevent loop unrolling etc. but I still have to use trial and error to find the right place.
Do you have any better strategy than changing random places and seeing what makes a difference?
Ca vous manque les speedruns depuis hier ? Voila un after : vers 21h00 Speedrun #livecode#glslhttp://twitch.tv/FieldFxDemo :D . Et y'a alkama
au platine, ouais ouais ouais !!!