I spent a ton of time over the past several months looking for a decent IDE around which to start seriously expanding my shader code ecosystem. Since I have quite a few custom bindings, I can't use a standalone suite out of the box, but require something that is strongly typed while also being able to leverage dynamic shared code. I want to stress that I'm NOT looking for a complete build/debug solution - just the editor/IDE portion so I can write shaders while expanding my codebase independently.
For months I thought there was nothing that would suit my needs since any extensions that deal with shading languages seem to be limited mostly to syntax hilighting. But I wanted so much more. Finally, lo and behold, I there was an answer to my call. Well, sorta. Although in all honesty it's actually a surprisingly good answer from my perspective. Thing is, it comes with a hefty caveat.
For the non-TL;DR crowd - here's what I want:
Enter Visual Studio Code with the C/C++ extension. Thanks to the similarity of GLSL to C, it can actually do ALL of the above (except for the first point, obviously), and the whole thing is free.
Here's some more words to set up the scene:
The offending construct is uniform blocks.
Take the following piece of code in GLSL:
layout(std140, binding = 0) uniform _uniblock {
my_struct _struct;
};
In GLSL, _struct is treated like a global. There are no namespaces or other scope-related concepts that would allow me to "extract" _struct from _uniblock. In fact, as far as I know, the uniform block is purely syntactic from a code-writing point of view and from a logical standpoint pretty much does not exist. This is an issue, because I want the C++ intellisense to treat _struct like a global, so I don't lose suggestions when I try to access its members.
Now, to hilight the type of connivery I'm employing - in order to deal with the layout qualifier part, I'm resolving it through the following macro:
#define layout(arg) struct { int arg; };
As another example, in order to resolve something like:
precision highp float;
I'm defining the offending keywords and qualifiers as:
#define highp
#define precision typedef
Oh, and "uniform" is defined as:
#define uniform const
Of course this isn't valid code - but it's not supposed to be. After the replacement, vscode thinks it's valid and consequently doesn't complain. Which is exactly what I want so long as I don't make a mistake while writing the shader.
Now I want to apply the same kind of logic to the uniform block problem to get rid of the implicit scope as invisibly as possible. Basically anything goes - macros, typedefs, type obfuscation via templates, and - if all else fails - modifying the GLSL syntax using the preprocessor as long as the resulting code will compile without any additional modifications.
Ideas?
PS - I hope my description was in the very least marginally clear
↧