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.

I checked and it's really not working as intended, it should be fixed if possible.

But I found an workaround that can make things simpler: just use "Attach to object" and set the padding to 32, it automatically positions, rotates and resizes the panel to match the object.

Thanks for the explanation.

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

...

int radius = radius2 * 2 + 1;

...

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?

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

There is info HERE about it.

I just tried it with the image from this thread and if you zoom right in after applying the effect, it seems to create gradations in the shadow.Thanks for the info. I changed from ps_3_0 to ps_2_a and it worked for me. I guess my graphics card doesn't support PS 3.

Both of those require a special setup with your images.

They are basically experiments that need a bit more work.

So unless you know all about shaders they are kinda useless.Do you have any info on how to setup the images? I'm interested in playing with it and see if I can turn it into something more useful.

As far as I can understand it applies a blur on the red channel, than calculates the difference between the blurred pixel and the original, than compares that to cutoff and threshold and generates an alpha that is applied to a black texture.

It should give some visible results on any image with some variation on the red channel, but it doesn't seems to be working. I guess it's because it is defined as a PS 3.0 shader.

A hexgrid is basically a square grid with odd rows offset by half cell width. You can do that by using modulus, so you just add 'half width' multiplied by the 'row index' mod '2', to the X coordinates.

here's a cap:

http://dl.dropbox.com/u/7871870/construct/hexgrid-01.cap

*Edit: if you want a more precise solution I found some links for reference:

http://playtechs.blogspot.com/2007/04/hex-grids.html

http://gdreflections.com/2011/02/hexagonal-grid-math.html

http://www-cs-students.stanford.edu/~amitp/gameprog.html#hex

If there's a simpler way then please do tell me.If not would using pv more manageable than the other ways? Or am I understanding this all wrong and infact hash tables and arrays are nothing like pv (I know arrays are different).I would probably use global variables for this. Although, I'm not sure if you are aware of, but there's an expression that returns the number of instances of an object (Get number of objects), so you don't need to create your own counter depending on the case. You just need to use a System "Compare" condition and put it like "Sprite.Count < SpriteMaxCount".

That's really nice. Clever solution!

With some little tweaking you can create a level-map very fast:

http://dl.dropbox.com/u/7871870/construct/auto_tile-01.cap

-left click create

-right click destroy

The only thing I'm not sure is - does the transform matrix need to be multiplied with the input colour?

Sure it needs, that's where the HSV transformations are applied to the original texture colors.

Looking into it further it seems that the default transform values assume a default display gamma of 2.2 which may well be the case for our regular everyday visuals, but possibly less so for the DirectX based CC output. Thus the end result becomes darker? Not really sure.

I have not enough knowledge about this subject, can't really tell you anything for sure.

Hey, super-great effect, but there's a little problem - it seems to adjust something (looks like brightness) besides the hue.

Could something need fixing or is this just the way the graphics card does this?

This effect is an adaptation of a code I found on internet. It uses some pre-calculated values to speed things up and make it more feasible to be used as an real-time effect. I believe that probably there's some rounding going on that introduces some distortions.

I don't think that there's much way to improve it, since I don't know how the pre-calculated values were derived. Anyway, I may be wrong, since programming is not my expertise. But I think this distortions must be something intrinsic to this approach.

3. Are you planning on adding a side scripting version of construct, or is it going to remain purely graphical? ... Don't get me wrong, i like the graphical form too, just would like code preview bit or something added as another way to look at game logic.

I think about this pretty often and also in lots of uses for it. Unlike the way I think Ashley is seeing it, for me it would not be a new scripting system, just a conversion of the current events to text.

If you think about it, people already do this kind of conversion naturally in the forums, it would be just a matter of standardize it.

+On myButtonSprite left clicked

-> myButtonSprite: Set animation frame to 2

-> do something awesome

+ Powerups: Is Dragging

-> Powerups: Set position to (Int(MouseX/32)*32), (Int(MouseY/32)*32)

Besides being better for visualization and code review in some situations, it could also be printed for portability and sticked into walls to assist game development.

If the inverse conversion would also be true (text -> events), besides the obvious script alternative as some prefer, it would also be extremely useful for collaborative work. People could join events much easier by simple copy-pasting code, and even quickly transform forum posts discussions into construct events to almost instantly run and test it!

I believe a system like this for joining events have potential to be a lot more solid and less prone to bugs than implementing a direct event-editor pasting, since you could paste the text-events in the "script-editor", then revise and correct any missing object references before converting to real events by pressing a submit button.

So in the end I do not think it would require creating an entirely new script, as it kind of already exists inside Construct. All the necessary text code is already available in the event-editor. What it needs is symbols and/or formating to specify conditions/events,sub-events and actions.

Also there would not be any more problems in converting it to javascript beyond the ones that could happen within events, since in the end everything would be converted to events and those would still be the "real-code" run by the machine.