Shaders - case sensitive?

I was just working with some shaders (merely editing ones that already exist to try to give myself some experience with working with them) and I noticed that they seem to be case sensitive. Specifically, I had one reference to something called "underWaterWobble" (the lower case U was a mistake) when other parts of the code had "UnderWaterWobble". This was enough for GZDoom to not be able to find the required information and so the shader did not compile and GZDoom did not start. Changing "underWaterWobble" to "UnderWaterWobble" got things working. Then I changed it back to "u", just to double check and, sure enough, it failed again.

Obviously GZDoom is normally case insensitive to just about everything - so I wondered if this was correct behaviour? Perhaps there is something in the spec for shaders that specifies case sensitivity?

Pretty sure that's not something gzdoom can change. I mean, its scripting is kind of an outlier for being case insensitive in the first place, tbh - most everything else is case-sensitive.

I was just working with some shaders...

Wee need to talk!

Yes, GLSL is case sensitive.

GLSL is something that is beyond GZDoom's control - technically GZDoom could change its internal compiler to be case-insensitive but that would actually break compatibility with OpenGL in general - and if you are in OpenGL mode your GLSL code actually gets passed as-is (with some decorations to define uniforms and make it work right) right on to your video card's driver for it to compile outside of GZDoom and the shader programs will then run as requested on their defined surfaces.

GZDoom has a GLSL->SPIRV compiler (which is just technically a SPIRV compiler, if I understand things correctly, SPIRV is a dialect of GLSL created for Vulkan) that can be handled from the application side rather than being driver dependent, but that's only used when running Vulkan.

GZDoom has a GLSL->SPIRV compiler (which is just technically a SPIRV compiler, if I understand things correctly, SPIRV is a dialect of GLSL created for Vulkan) that can be handled from the application side rather than being driver dependent, but that's only used when running Vulkan.

Even then, that compiler needs to obey GLSL specs which are case sensitive. So even if you changed the compiler, you still wouldn't be able to find your uniform if the case didn't match.

(which is just technically a SPIRV compiler, if I understand things correctly, SPIRV is a dialect of GLSL created for Vulkan

Actually, SPIRV is an intermediate language, aka byte code. That's why there's also a HLSL compiler outputting SPIRV now. While I suppose you could say anything generating a .exe could be called an executable compiler, we generally don't call them that.

Ah, I see, thanks

Thanks for all the answers and subsequent discussion. I thought that it probably was the situation that it was part of the GLSL spec and that, as such, it was something outwith GZDoom's control but it was worth checking.

It's been a while since case sensitivity has caught me out like that (mostly because GZDoom ignores case most of the time) and initially the error message that I was getting didn't mention the element in question by name. So I was scratching my head a bit. Later on, after me adjusting stuff, the message did mention "underWaterWobble" and, straight away, the lower case u jumped out at me. Fixing it fixed the problem that I was having.

I'm not doing anything fancy, or even particularly meaningful, with the shaders. I'm just picking apart some of the shaders from Total Chaos, SWWMGZ and BoA just to see what they do, what they look like when applied to specific textures/model skins and how changing parameters etc changes their appearance. Interesting stuff.

This additional shader related question isn't particularly close to the original one, but it doesn't seem worth starting a new thread for.

I noticed that some of the whole-screen shaders have comments like "return black if the resulting coord isn't on screen" and that got me wondering - there are several mods that use weapon graphics, or overlays or ACS to print images to screen (e.g. sniper scopes or the gas mask in my own Burghead mod). Generally, people make these graphics pretty wide to cover as many monitor aspect ratios as possible, but technology and fashion keeps marching on. Screens seem to get wider and wider who knows about future 360 views, the further rise of VR or whatever? So, despite the best efforts of modders, it seems that - sooner or later - a user will be playing with a setup that means that they can see past the side of the sniper scope/gasmask/spacehelmet/whatever and thereby completely ruin the effect.

The gas mask graphic from the original version of my Burghead mod shows the problem if I put in a 21:9 aspect ratio. And at 856x480 I already thought it was wide enough to be future-proof.

(Also, the mod really, really needs to be updated on idgames with my fixed version from the project thread - the number of errors that spewed to the console and the fact that it didn't even go to the correct map on startup when I ran this is embarrassing.)

So, anyway, could this be solved by a scene shader? I'm thinking something like the size of the central image (the scope/mask graphic) can be defined in the shader *somehow* and then, if coordinates fall outside this defined size, draw black pixels to ensure that parts of the scene not covered by the graphic are always drawn black. That way, even if a user has a soopar 1337 (yes, even in the 2020s I just used 1337) 64:1 real world™ wraparound 128K total immersion™ monitor, when they look through the sniper scope/gas mask, they can see what is visible through the viewfinder/lens and the rest of the scene is black.

Is that a thing that could be done? Of course, if it could, I wouldn't even know where to begin but it does sound like something that might be useful as a community resource if someone who knows GLSL could do it.

While that could be done by a postprocess shader, I think in a situation like that screenshot it would probably be better if the 2d drawer was used to strech some black texture over the sides. That way it will work for everyone (i.e. those using software or the OpenGL ES backend).

I would deal with that by using Screen.Clear to cover the sides (needs 2 calls; one on each side). This would be done as a 2D drawer inside RenderOverlay (or RenderUnderlay, if the HUD should be visible on top of it).

The slightly tricky part is calculating how large the clear areas should be, based on the dimensions of the center graphic. Not difficult by any means, just extra consideration(and it needs to make sure it respects the scaling/virtual resolution of the graphic... TBH I hate anything involving screen coordinate scaling :D)

The 2D drawer idea does sound like it makes a lot more sense than the shader one. Of course, I have about as much idea how to do that (maybe even less) than I would the shader one.

Any idea if any projects have already done something similar so I could try to pick it apart and see how it works? I learn much better from having something that already works that I can then mess with and alter parameters etc than doing it from scratch if it is something that I effectively know zero about.

Continuing my adventures with shaders, I wonder if someone might take a look at the following shader code and tell me where I messed up (e.g. if I have done something illegal/pointless/missed out something that might cause a problem if the shader is doing its thing for a long time etc etc) and where it can be improved.

---

Code:

vec4 Process(vec4)
{
   // Get colour
   vec4 TexColour = getTexel(vTexCoord.xy);
   vec4 FinalColour = TexColour;
   
   // Calculate "TexMov1"
   vec2 TexMov1Uv = vTexCoord.xy; TexMov1Uv.x += timer * .2; TexMov1Uv.y += timer * .1;
   vec4 TexMov1Colour = texture(smoketex1, TexMov1Uv);
   TexMov1Colour *= TexColour; // Colourise TexMov1
   
   //Calculate "TexMov2"
   vec2 TexMov2Uv = vTexCoord.xy; TexMov2Uv.x -= timer * .1; TexMov2Uv.y += timer * .2;
   vec4 TexMov2Colour = texture(smoketex2, TexMov2Uv);
   TexMov2Colour *= TexColour; // Colourise TexMov2

   //Put it all together
   FinalColour += (TexMov1Colour + TexMov2Colour);
   return FinalColour;
}

It does actually compile and seems to work. It even, more or less, does what I want (creates a smokey effect on top of a texture without particularly dulling the brightness of the texture). However, I'm sure that I will have messed up somewhere because, frankly, I don't really know what I am doing and I am stabbing in the dark.
Full disclosure, it is based on something I found in BoA, with a little influence from stuff from SWWMGZ and a lot of my hack-and-slashing the code to make a right mess of it.

But, like I said, it does do what I want:

Fuego.pk3

You do not have the required permissions to view the files attached to this post.