We closed this forum 18 June 2010. It has served us well since 2005 as the ALPHA forum did before it from 2002 to 2005. New discussions are ongoing at the new URL http://forum.processing.org. You'll need to sign up and get a new user account. We're sorry about that inconvenience, but we think it's better in the long run. The content on this forum will remain online.
IndexProgramming Questions & HelpSyntax Questions › A fast alpha() question
Page Index Toggle Pages: 1
A fast alpha() question (Read 264 times)
A fast alpha() question
Mar 2nd, 2009, 8:54pm
 
I have several times tried to use the alpha() function, but it seems to be a bit bugged.
Alpha() should be a float, right? But is acts like an integer to me.
Has anybody else noted it?

Well heres one small app where I tried using it.

I cant quite spot where the problem is, so if you see something I dont I would love to hear.
The variable opa is the alpha  value for the rect drawing over the screen at each frame. How come values between 0 and 1 doesnt have any effect.



float opa = 1;

void setup(){
 size(500,500);
 smooth();
 background(0);
}

void draw(){
 noStroke();
 fill(0, opa);
 rect(0,0,width,height);
 float n1 = mouseY-pmouseY;
 float n2 = mouseX-pmouseX;
 float b1 = norm(n1, -50, 50);
 float b2 = norm(n2, -50, 50);

 stroke(random(220,255), random(100,255));
 float y1 = (random(-n1,n1))*6;
 float y2 = (random(-n2,n2))*6;
 rect(mouseX+y2,mouseY+y1,5+b1,5+b2);

 //mkusk
}
Re: A fast alpha() question
Reply #1 - Mar 2nd, 2009, 9:49pm
 
You're right about some strange behavior in the default render mode (Java2D) but everything look fixed if you use P2D or P3D.

-> size(500,500,P2D);
Re: A fast alpha() question
Reply #2 - Mar 2nd, 2009, 11:11pm
 
Hi, thanks for the quick reply.

It works (better).

I still think there is something not right when the numbers gets very close to zero, but I guess in that case another method would better, I just dont know which.

Re: A fast alpha() question
Reply #3 - Mar 2nd, 2009, 11:14pm
 
Wrong. But I won't blame you, the info isn't obvious to track.

In fill(), alpha is int or float. No explicit range for the value is given.
Same issue for color(), but it points to color datatype.
There, it is said: "Each component is 8 bits (a number between 0 and 255)." And that's also the default range for alpha.
But then, why alpha() return a float? It cannot return an "int or float", because Java functions return only one type. So they chose the most flexible format.

And why "int or float"? Look at colorMode(): it allows to choose whatever range is convenient for you. Can be default 0 to 255, but can be also 0.0 to 1.0 (or 0.0 to 0.5 or to 2.0, etc.). Hence the needed flexibility.

But your code sample doesn't use colorMode(), so alpha is default 0 to 255 and an opa of 1 is almost completely transparent.

Wew! Smiley
Re: A fast alpha() question
Reply #4 - Mar 2nd, 2009, 11:25pm
 
But does that answer why, if I run

size(500,500);
and alpha() on the fill() on a very small number. Lets say 0.00001 or 0.8 for that matter, that it doesnt blend at all?
In the code sample below the value is very close to 1, but it doesnt blend whatsoever, on 1 it blends very fast.
I know the Alpha function is multiplicative, guess that means it will never hit 255 or 0, but i should be able to get infinitely close, no?

Anyway, thanks for your reply, I just dont think it the right explanation.

float opa = 0.8;

void setup(){
 size(500,500);
 smooth();
 background(0);
}

void draw(){
 noStroke();
 fill(0, opa);
 rect(0,0,width,height);
 float n1 = mouseY-pmouseY;
 float n2 = mouseX-pmouseX;
 float b1 = norm(n1, -50, 50);
 float b2 = norm(n2, -50, 50);

 stroke(random(220,255), random(100,255));
 float y1 = (random(-n1,n1))*6;
 float y2 = (random(-n2,n2))*6;
 rect(mouseX+y2,mouseY+y1,5+b1,5+b2);

 //mkusk
}

Re: A fast alpha() question
Reply #5 - Mar 3rd, 2009, 10:49am
 
Are we discussing of the same Processing? I have Processing 1.0.1 on Windows XP.

If I run your sketch, I see no blending except the brightest squares fading a bit.
I see no difference with opa at 1 or 0.8 and at 0.1, the brightness change is unnoticeable, if there is any.
It is normal, near 0, alpha is nearly fully transparent.
If I set a higher opa, say 100, the squares disappear nearly instantly. At 10, there is a nice fading effect with a bunch of squares.
Re: A fast alpha() question
Reply #6 - Mar 3rd, 2009, 3:18pm
 
I run on OSX, but also ver 1.0.1.
The reason I asked is that on alpha 1 it fades too fast and on 0.8 it hardly fades at all.
That doesnt make sense to me.
But I will try it on Windows when I get the chance.
Re: A fast alpha() question
Reply #7 - Mar 3rd, 2009, 3:22pm
 
Okay, heres the definite answer.
Apparently I dont do math. (I kind of suspected it)

"
Colors are stored as values between 0 and 255. If you have a value of 0.8,
that doesn't meet the threshold of 1.0, so when binned to 0 and 255, you
get 0. To fix this we'd have to use more than 8 bits of color per pixel,
storing the entire image as higher resolution than what's on the screen,
and then downsample it before drawing.
"
Re: A fast alpha() question
Reply #8 - Mar 3rd, 2009, 3:28pm
 
And the solution (in case anybody cares Smiley)
Phil was rigth, of course Smiley

I just set colorMode() to eg. colorMode(RGB, 1000);
And then the alpha to 1.

Jeez, it wasnt that hard.

Thanks for the help guys.
Page Index Toggle Pages: 1