I'm afraid there is no way for the particles, apart from doing you own particle generation with sprites through events.

Controlling the audio channels is a lot more easy. Just uncheck "Timescale audio", then select all the channels that you want to be affected by timescale, and set them to a frequency fitting timescale.

Example:

+ System: For "" from 1 to 5
-> XAudio2: Set channel LoopIndex frequency ratio to TimeScale
[/code:36jmw24x]

I hate you all! No, really

Most of the artwork presented here is not only good, it's fantastic. I mean, just look at the work of saint11, pyteo, inkBot, frpnit or Julmust. They are so professional by any positive means.

And me?

average programming skills

average music composing skills

average writing skills

below average drawing skills

...

If I only had 5% of your skills!

Damn!

*walks away crying and full of self-pity*

As an addition:

http://www.scirra.com/forum/viewtopic.php?f=8&t=6880&p=53876#p53876

The Offset effect isn't safe for negative values. The TiledBackground object is safe for negative values, but offsetting only works with power-of-two-images.

In your case the easiest solution is to use the tb object, because the image is of a power-of-two-size.

But for those curious: You need to do the wrapping on your own (until the offset effect is updated). Here is how (using the example file from above): http://dl.dropbox.com/u/11182740/offset%20help.cap

In fact, i'd like to be able to import like 3 mask textures packed into a single RGB file, as the memory will handle it as a single texture. I'd use those for operation on the screen like to simulate the shadow of the clouds on the ground or so.

I see. And I confirm. This is a task for pixel shaders und doable (although not easy). Depending on your needs you have to write them first, of course. Feel free to pm me, should you get in trouble regarding Construct's implementation of HLSL.

- it's possible to extract independently the R, G and B channels of a texture to treat them separately (with shaders) ?

If you only need to output to screen, then yes, this is easy with pixel shaders. If you want to save such altered textures, you would need the canvas/image manipulator objects.

- if the size of a texture used in a level should be using a power of 2 (128*256 etc.) to increase performances ?

No. General size, count and the display size matter, but a non power of two texture shouldn't affect performance (if the gfx card requires such texture formats, the image you use will be stored as a padded power of two anyway).

- if construct can work with tiling textures the 3d way (you can tile as many time as you wish a bitmap on a defined surface)

Not sure, what exactly you have in mind. The tiled background object does that, but I assume you want to tile some other shaped objects? If so, this is possible indirectly, using the shape as a mask and project other objects like the tb onto it (using pixel shaders).

- if it is possible to post process the entire screen at once (lens vignetting) ?

Yes. Some effects work very well as layer effects, processing the whole background to that layer. Furthermore the canvas object, set to "after drawing" also is suitable as a post processor. (btw: there already is a good vignette shader that ships with Construct)

Its a good example...

No, it is not. I thought, I made the problem clear when I was posting in this thread, but I will explain it once again.

The slicing that was done here is just replacing one memory-waste-sprite with 36 not-so-obvious-memory-waste-sprites. The original image was 700x700, which totals 1960000 bytes (1.87 MB). On most graphic cards the resulting sprite will consume the next power-of-two size, which is 1024x1024 and totals 4194394 bytes (4 MB).

So, why is this example not a good one? Is does save memory, doesn't it? Yes, it does, but by chance.

1) The arranging of the 36 sprites was done wrong. The slices are of 4 different sizes: 116x116, 116x117, 117x116, 117x117. This was not taken into account and the sprites arranged on a 116 grid, leading to an image of the size 696x696, thus losing image information.

2) The slices created are of a non-power-of-two-size and also waste memory. All the 36 slices will consume the next power-of-two-size, which is 128x128 in this case. If the original image would have been splitted into 49 or even 64 pieces, the resulting memory use would have been the exact same. If it would have been splitted into 25 pieces, it would even use 256x256 per piece. Just because it wasn't splitted into power-of-two-sizes.

I remade the example to show, that you can reduce the (texture) memory usage to exactly the size, that the original image consumes:

I won't comment on the "do we need to save memory"-issue. But, if you decide to split up your images, then do it consequently. Always split them into pieces of power-of-two-sizes (the magic of power-of-two is that you can represent any number!)

Here's the cap: http://www.mediafire.com/file/qec45byuwxb0q29/BetterExample2.cap

random(50) will generate a number between 0 and 49 (including both). The resulting number would be between 50 and 99 (including both). If you need your number to reach 100 sometimes as well, you would need to do 50 + random(51).

(May not be important, but I thought I should mention it)

I think there is a need for ripple effect, too.

I tried to, but the result was far from good. If anyone knows a better algorithm, please post. I'd love to do a ripple effect.

... lets say to Quaziballs? or whatever they we're

I think the correct name is Quaziblobs? and my blob-shader is based on them (an example of the effect is also flying around here somewhere)

> ...
if findpath == 'true':
	findpath == 'false'
	...[/code:2wyumo0u]

That's the only part I could find. You don't assign "false". Correct it to

findpath = 'false'[/code:2wyumo0u]

Even if you don't want to use the auto-zoom-engine, why not take a look? And then just copy the parts that do what you need