0 Favourites

[FX] param related with For conditional error

This forum is currently in read-only mode.
• 5 posts
• I'm messing arround with an adjustable gaussian blur effect where you can set the blur radius. It uses a For statement and check if the iterator is smaller than the "radius*2+1" to calculate the blur. It happens that it work alright if I set the radius value through code, but as soon as I relate the radius with an adjustable parameter it gives this error:

<img src="http://dl.dropbox.com/u/7871870/construct/blur_error-01.jpg" border="0">

It seems that whenever I relate a parameter to the conditional of a For statement it breaks the effect. Anyone knows why this happens or if there is any workaround?

Here is the effect: http://dl.dropbox.com/u/7871870/construct/Gaussian%20Blur%20H.fx

• HLSL doesn't support "dynamic looping" prior to 3.x

Loops will be unrolled and therefor the bounds are needed to be known. That's why it works when setting the var through code.

Limitations:

• 1023 iterations max (if no instruction slots or const registers are used)
• 64 instruction slots max
• 31 const registers max

You can fake HLSL by using modulo, but with the listed limitations, you have to limit the code to modulo 7.

Code example snippets:

...

...

for (int i = 1; i < radius; i++)

When changing the formula or the loop and its content, you have to change modulo also to limit to the max bounds (above you'd have a loop from 1 to 6), before an error raises. But as I said, this is faking so it would be better to find a method with a fixed loop.

• Thanks for the explanation.

But I still don't get why I cannot do something like this:

...

...

for (int i = 1; i < clamp(radius,1,7); i++)

In theory this limits the loop and defines known boundaries to it.

How the program determines that this loop will run forever?

I made a "Mask" version of this effect where the radius is determined by the foreground pixel and applies the blur to the background pixel. So the number of loop iterations changes according to the pixel input value. And it works.

Why a parameter, even with "defined bounds" through clamp, doesn't work the same? What makes a parameter more unknown than this pixel input?

Develop games in your browser. Powerful, performant & highly capable.

Construct 3 users don't see these ads
• I'm not very good at explaining such very specific things in english, so maybe my words are imprecise.

With 'fixed' I didn't mean a value that doesn't change, but a value known to and checkable for HLSL. The upper bounds check needs to be local (local to the effect function, defined within the effect function).

clamp() is a function and that's why it is like a black box for HLSL, while modulo is a specific operator.

I hope you can follow the above, because I don't kow how to express it else <img src="smileys/smiley9.gif" border="0" align="middle" />

EDIT: Maybe this makes it a bit more clear.

radius = clamp(radius2, 1, 6); // sets radius = clamp(unknown, 1, 6), which makes it still being unknown

radius = clamp(radius, 1, 6); // sets radius = clamp(known, 1, 6), which makes it still known

• Thanks for the enlightenment tulamide, now I understand the general logic behind it.

So I guess a saturate() function or a sampled pixel is considered as a know value just like modulo, because it can only fall between 0 and 1. At least I used that for the mask effect and it didn't complained.

I don't want to set a fixed amount of samples for this blur, so I guess I will use the mask version and control the radius with the color of another object or layer.

Thanks again for the info.

• 5 posts