ISF Macros in comments
Posted: Mon Aug 31, 2026 10:28 pm
IMG_ macro names work fine everywhere they are actually used, but writing one in a comment stops the shader compiling.
If I put IMG_NORM_PIXEL or IMG_SIZE in a comment as a bare word, with no argument list after it, the shader fails to compile, and the errors point at unrelated lines of correct code further down the file rather than at the comment.
Here is a minimal case. It declares one trivial function and writes a gradient. The only unusual thing about it is the three comment lines.
Magic reports:
0(23) : error C0000: syntax error, unexpected '(' at token "("
0(29) : error C0000: syntax error, unexpected '=', expecting "::" at token "="
Neither of those is the comment, and neither line has anything wrong with it. Delete the three comment lines and the file compiles and renders unchanged.
I narrowed it with four more files, each changing one thing:
a bare macro name in a // comment - fails
the same name in a /* */ block comment - fails
the same name followed by a full argument list, IMG_NORM_PIXEL(inputImage, vec2(0.5, 0.5)) - compiles
RENDERSIZE, PASSINDEX and TIME named in a comment - compiles
So it is the IMG_ family specifically, it is only when the name is not followed by an argument list, and comment style makes no difference.
This looks like the same class of problem as the reserved words in comments issue that was fixed a while back, so it may be a regression or a second path into the same code. What makes this one difficult to diagnose is that the error message never mentions the comment, so it sends you off to rewrite code that is already correct. It has cost a lot of time even with Claude helping.
Came up when testing multi-pass buffer work, where I'd commented what I was trying to test.
If I put IMG_NORM_PIXEL or IMG_SIZE in a comment as a bare word, with no argument list after it, the shader fails to compile, and the errors point at unrelated lines of correct code further down the file rather than at the comment.
Here is a minimal case. It declares one trivial function and writes a gradient. The only unusual thing about it is the three comment lines.
Code: Select all
/*{
"CREDIT": "",
"DESCRIPTION": "",
"CATEGORIES": ["Utility"],
"ISFVSN": "2",
"INPUTS": [
{
"NAME": "inputImage",
"TYPE": "image"
}
]
}*/
// This comment mentions IMG_NORM_PIXEL and IMG_SIZE by name.
// The readout samples four corners with IMG_NORM_PIXEL and never calls
// IMG_SIZE on a pass target.
float sq2(float x) { return x * x; }
void main() {
vec2 uv = gl_FragCoord.xy / RENDERSIZE;
gl_FragColor = vec4(sq2(uv.x), sq2(uv.y), 0.25, 1.0);
}
0(23) : error C0000: syntax error, unexpected '(' at token "("
0(29) : error C0000: syntax error, unexpected '=', expecting "::" at token "="
Neither of those is the comment, and neither line has anything wrong with it. Delete the three comment lines and the file compiles and renders unchanged.
I narrowed it with four more files, each changing one thing:
a bare macro name in a // comment - fails
the same name in a /* */ block comment - fails
the same name followed by a full argument list, IMG_NORM_PIXEL(inputImage, vec2(0.5, 0.5)) - compiles
RENDERSIZE, PASSINDEX and TIME named in a comment - compiles
So it is the IMG_ family specifically, it is only when the name is not followed by an argument list, and comment style makes no difference.
This looks like the same class of problem as the reserved words in comments issue that was fixed a while back, so it may be a regression or a second path into the same code. What makes this one difficult to diagnose is that the error message never mentions the comment, so it sends you off to rewrite code that is already correct. It has cost a lot of time even with Claude helping.
Came up when testing multi-pass buffer work, where I'd commented what I was trying to test.