Built-in Shader Encoding Issues

[xezno]

(From Discord): users with non-Unicode default encoding (such as shift jis) currently experience the following engine crash on startup:

Theories:

• The string is being encoded in shift jis but the shader compiler (glslang) expects utf-8
• The shader compiler expects to convert from the user's locale to utf-8, but is passed a utf-8 string instead
• Something else

I am not at all experienced with character encoding so I'm not sure what could be causing this right now.

[MuffinTastic]

So after a closer look I'm now about 90% sure this isn't an encoding error. I led with that assumption because I've been burned too many times by other programs on things relating to text, my mistake. It not being an encoding error is made more likely by the fact that the issue has remained even after setting both my system locale/encoding to UTF-16 and my display language to English. If you agree, perhaps it's best to revert these two commits: 1ca21f4639980193b4bb357407361f3ca446224c, 82491fa8e6ff9e99934e2837f6ee09fc627d63ae. They didn't do anything for me one way or the other.

Anyways, with that out of the way I did some more digging online for the 0xCD byte that keeps appearing (appearing as ﾍ in that screenshot) and found some other people with similar problems, and it all came down to badly terminated C strings (or other sorts of strings mistakenly interpreted as C strings) and the CRT pre-initializing newly allocated memory on the debug heap to that value. Consider that vTexCoord is 9 characters long, then there's 7 of that magic 0xCD byte, and then the last character is a tab - to me, this looks suspiciously similar to padding for byte alignment.

I've stepped through the execution of the shader loading code line by line on debug builds, keeping an eye on local variables, and at no point does it get corrupted as far as I can tell, certainly not within Mocha itself. I'm not sure why the string would ever be split up in the first place, unless it's getting parsed, so my working theory is that this is some kind of glslang issue.

Since this has to do with the debug heap, on a hunch I set it to compile in release mode, and lo and behold, the shaders compile, and the engine moves on all the way until the main loop. Can't say if the shaders work yet, I've got some other (probably?) unrelated issues to work through first. All of that being said... I don't even know why this works.

For all I know, all of this could be specific to my PC, so I'll be wiping my environment completely and starting over tomorrow just to be sure.

[xezno]

the CRT pre-initializing newly allocated memory on the debug heap to that value

This checks out, when compiling a release build these won't get filled, but whatever memory it's allocating might just happen to contain or be filled with 0x00, which would null-terminate the string when strcpying into the allocated memory.

This does indeed look like it's probably an issue within glslang itself. It might therefore be best, both to fix this bug & for workflow reasons, to switch away from inline shaders like this and instead just compile these shaders directly as .spv files, which should negate this issue entirely.

[xezno]

Turns out this was caused by a bad compile or something, and that recompiling glslang specifically seems to have fixed it. I'm going to close this for now but if anyone else comes across this issue, please let me know.