click on them to view in full screen.
I’m experimenting what can be done in 2kb with flash. The Scion was also one of those tryouts. I use Pixel Bender here and it seems to be the best tool for low bytes works. Here are couple of things I figured out while playing.
You don’t need to setup the default values. Following works just fine.
Also the metadata can be written like this:
kernel a <namespace:"";vendor:"";version:1;description:"";>
The fastes way to calculate distance between two points in PB:
float2 point1 = float2(1.0,1.0);
float d = length(point0-point1); //not accurate but useful enough
I’m not quite sure about this but it seems to me that it’s much faster to calculate sin(), cos(), atan() values in Flash then in PB. :) So avoid calculating same math for each pixel.
If someone knows more tricks please share.
*** [update 2010-05-14] ***
Here’s how to create a class function (sort of..)
void evaluatePixel()
{
float2 p = outCoord();
calculate_something(outpixel,p.x);
}
Here’s the way to do a loop in Pixel Bender
void evaluatePixel()
{
float myColor = 1.0;
loop(myColor, 0.5); //myColor = 0.5
loop(myColor, 0.5); //myColor = 0.25
loop(myColor, 0.5); //myColor = …so on.
loop(myColor, 0.5);
loop(myColor, 0.5);
outpixel = float3(myColor,0.0,0.0);
}
“it seems to me that it’s much faster to calculate sin(), cos(), atan() values in Flash then in PB” – so you are saying here that calculating various math stuff once and passing through params is faster than doing so inside for every pixel? I would expect this to be true for any image just large enough :) or, if you mean to calculate 2D sin/cos fixed point (bit)maps and pass as 2nd source to sample from, then I am surprised.
Yeah, I know I put it up very stupid way :) Anyway the point is to calculate as little as possible in PB or split heavy calculations into separate kernel.
Simple rule for increasing performance would go something like: “find the way to calculate that outside the kernel and use PB for render only”
If you have some heavy math operations that are the same at each pixel (ie: are not dependent on the pixel), then it may be faster to pass them in as parameters or use #define statements to make them constants. Worth testing both ways to see.
Ohh.. didn’t knew that, nice!
So this is the way to do a ‘class function’ -type of code.
output pixel3 outpixel;
#define calculate_something(pixel,x) pixel.r = 1.0/(x*.01);
void evaluatePixel()
{
float2 p = outCoord();
calculate_something(outpixel,p.x);
}
Is that fast? This means I could do the looping quite easily just by adding the method call several times. Here are idiotic example that works :)
#define loop(res, i) res = i;
void evaluatePixel()
{
float myColor;
loop(myColor, 0.0);
loop(myColor, 0.0);
loop(myColor, 1.0);
outpixel = float3(myColor,0.0,0.0);
}
Opens a lot new possibilities. Is there more this kind of stuff that I should be aware of?
What do I think? I think you’re awesome!
there are two small problems with that kind of loops, 1st you can’t get rid of if() calls (at least) even if you only need 5 out of 1000 iterations for this kernel run. 2nd, bytecode is getting big. some dudes ported Uro’s asm in flash, and there was even example on wonderfl how to use it to compile loops at run-time with just right number of iterations (doesn’t solve #1 per pixel, but at least does so per image)… let’s see if I can find it… here http://wonderfl.net/c/6GQX