Variables Scope in GLSL.

[Knurz]

Hi Guys!

I'm starting to get to know GLSL a little bit better and I tried a simple Copper/Rasterbars Shader to get more familiar with the language.
The Shader uses a for-loop to determine if some bar are in distance of the current normalized position...

Code Select Expand


for (int c=RASTERS; c > 0; c--) {
float jd = sin(time+(ANG2RAD*float(c)))*0.2;
yd = 1. - (1./maxRast* abs( jd+YBASE - p.y));
if (yd > 0.) {
break;
}
}


I'm a little bit curious about the for-loop initialization and the scope of it's variable "c". If I declare the variable outside of the loop, it works but the value in c is not correct AFTER the for loop has finished - as you can see if no hit occures c should be 0, or should have the "bar"-counter. If I don't declare the variable outside the compiler mocks me that c is not declared (which is a C-like-scope behaviour).

So for now I took a 2nd variable, and if a bar is in distance I copy c to the 2nd variable..

The Scope-behaviour seems different from C.. or I didn't get it right. It seems that this behaviour of scope is only with for-loops...

Have I done something wrong with GLSL or is this the normal behaviour (which would be very curious!) ?

Have a nice day and greets

[hellfire]

If I declare the variable outside of the loop, it works but the value in c is not correct AFTER the for loop has finished

You mean the following does not work?

Code Select Expand


int c;
for (c=RASTERS; c>0; c--)
{
  if (...) break;
}
// do something with "c" now


[Knurz]

If I declare the variable outside of the loop, it works but the value in c is not correct AFTER the for loop has finished

You mean the following does not work?

Code Select Expand


int c;
for (c=RASTERS; c>0; c--)
{
  if (...) break;
}
// do something with "c" now


Hi hellfire.

Nope, at least not in GLSL-ES (I'm trying it in glsl.heroku.com's Sandbox)

My intention was to make the Bars which are in background darker than that which are more in foreground.

Code Select Expand


       ....
int c = RASTERS;

for (int c=RASTERS; c > 0; c--) {
float jd = sin(time+(ANG2RAD*float(c)))*0.2;
yd = 1. - (1./maxRast* abs( jd+YBASE - p.y));
if (yd > 0.) {
break;
}
}
sb = 1./float(RASTERS)*float(c);
yd *= sb;
        ....


Doesn't work.. (all bars are same bright)

Code Select Expand


int r = RASTERS;

for (c=RASTERS; c > 0; c--) {
float jd = sin(time+(ANG2RAD*float(c)))*0.2;
yd = 1. - (1./maxRast* abs( jd+YBASE - p.y));
if (yd > 0.) {
r=c;
break;
}
}
sb = 1./float(RASTERS)*float(r);
yd *= sb;
gl_FragColor = vec4( baseCol.rgb * yd, 1. );


Works...

I can live with that behaviour but it makes me a little curious how GLSL is handling the scopes of variables..

Bye.

[hellfire]

Code Select Expand


int c = RASTERS;

for (int c=RASTERS; c > 0; c--) {
float jd = sin(time+(ANG2RAD*float(c)))*0.2;
yd = 1. - (1./maxRast* abs( jd+YBASE - p.y));
if (yd > 0.) {
break;
}
}
sb = 1./float(RASTERS)*float(c);
....


Here you've got two "c", one outside and another one inside of the for-loop.
The one inside the loop disappears when the code leaves the for{}-scope.

[Knurz]

Here you've got two "c", one outside and another one inside of the for-loop.
The one inside the loop disappears when the code leaves the for{}-scope.
[/quote]

If I didn't declare the variable within the for-loop, the compiler at herokus mocks me that the for loops initializer is not correct.

Code Select Expand


int c;

for (c=RASTERS; c > 0; c--) { <=== "invalid init declaration"
float jd = sin(time+(ANG2RAD*float(c)))*0.2;
yd = 1. - (1./maxRast* abs( jd+YBASE - p.y));
if (yd > 0.) {
break;
}
}
sb = 1./float(RASTERS)*float(c);
yd *= sb;
gl_FragColor = vec4( baseCol.rgb * yd, 1. );
}


Code Select Expand


int c;
for (int c=RASTERS; c > 0; c--) {


No compiler error, but also no output...

Code Select Expand


int r;

for (int c=RASTERS; c > 0; c--) {
float jd = sin(time+(ANG2RAD*float(c)))*0.2;
yd = 1. - (1./maxRast* abs( jd+YBASE - p.y));
if (yd > 0.) {
r=c;
break;
}
}
sb = 1./float(RASTERS)*float(r);
yd *= sb;
gl_FragColor = vec4( baseCol.rgb * yd, 1. );
}


Works fine...

Maybe this is a OGL-ES specific behaviour ?

brgds.

[hellfire]

Maybe this is a OGL-ES specific behaviour ?

Most probably yes. Actually loops do not exist in glsl-es. But the compiler is so kind to unroll the loop for you.
This might cause the loop-counter-variable to disappear; which is still terribly wrong of course...

[Knurz]

Most probably yes. Actually loops do not exist in glsl-es. But the compiler is so kind to unroll the loop for you.
This might cause the loop-counter-variable to disappear; which is still terribly wrong of course...

Ahh I see, this would explain the strange behaviour of the scopes.

Thanks for your explanation, I was just curious that the behaviour of scopes in GLSL differs so much from C.

Bye and have a nice day