Dark Bit Factory & Gravity
PROGRAMMING => General coding questions => Topic started by: Knurz on June 26, 2013
-
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...
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 :)
-
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?
int c;
for (c=RASTERS; c>0; c--)
{
if (...) break;
}
// do something with "c" now
-
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?
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.
....
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)
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.
-
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.
-
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.
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. );
}
int c;
for (int c=RASTERS; c > 0; c--) {
No compiler error, but also no output...
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.
-
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...
-
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 :)