-
Bug
-
Resolution: Fixed
-
21w11a, 21w14a, 21w15a
-
None
-
Confirmed
-
Crash, Rendering
-
Very Important
Currently playing with shaders/include/light.glsl for a pack I want to release.
Tried adding a "Made by: " multiline comment with a lot of *'s for style. Caused shader compilation to fail every time, or just straight up crash the game.
This does not occur with traditional // Single line comments.
My only guess is that this has to do with #moj_import? I haven't tried it with other shaders yet.
/***************** * Add me to an include shader to slow resource pack loading to a crawl! * :) * :| * :( * :(((((((((((((( ****************/
/******************************************************************
** This has a 25% Chance of actually just outright crashing the
** the game on F3+T reload, and 75% chance of failing resource
** pack loading. Which will reset every pack you had set to be
** not set. That's annoying. Really *really* annoying.
**
** I spent 2 hours on this problem. I really wanted to include the
** ASCII art of my birthday coyote too!
** ;-;
**
** Though really, I don't think the ASCII art helped either. It had
** a lot of *'s too.
**********************************************************************/
- is duplicated by
-
- Resolved
[MC-220024] Shader compilation slows or fails the more asterisks are in a multiline comment
Can confirm 21w14a, attached example resource pack
This occurs in normal shaders, and does not require a #moj_import to happen.
Indeed I have. The shader would compile perfectly fine without the multiline comment, in addition to it already having multiple newlines at the end.
A glossed-over look makes me think this is a problem with whatever GL library you're using.
So before you send the shader to "glCompileShader" or whatever wrapper func you use (I'm working off of de-obfuscation map'd stuff), do some kind of pre-preprocessing on the file to remove extraneous *'s (as I believe this is an issue with the compiler searching for the end of the multiline comment, and /* */ being a special case in that it's not ended by one character? Making assumptions, I don't know what's going on in there).
It's a hack but it'd probably work (assuming this is the root cause of the issue to begin with). Hell in that stage you could probably just remove the comment entirely, but at some point you just gotta bug the library creators about this instead of writing your own jalopy preprocessor.
Of course this is just a guess with minimal effort put behind it so I could (and probably am) wrong, at least about the source of the issue. I'm at least 60% confident in the guess that it has to do with looking for the end of the comment though.
EDIT: more looking has made me look like an idiot. blaze3d does have a preprocessor of its own. My bad.
Haven't looked through it extensively but I still think my 60% guess is the issue.