It looks like your actions all set slot1 to 1 in every event, so slot2 is never set. From what you wrote t appears that this isn't the intended behavior.

Why not just roll your own wrap code?

Yup, something like that, where you can climb up all the way to the top ! I'm not a big fan of score games, that's why I'm asking.

Yea, it's possible to reach the end of the game.

Scenario mode.. kind of like the event matches in Smash Bros? Their is a minor plot however, If you mean story mode. But there isn't any saving of progress.

Underwater.

<img src="http://dl.dropbox.com/u/1010927/Forumpics/Tcwater2.png">

So say your mean is 10, and the sigma is 10 you will get any random number between 10-10, and 10+10....

Kind of, but sigma is just the width of the bell curve. Specifying 10 doesn't actually mean it will give you a number that's either ten greater or ten less. Here, I made this .cap. A sigma of 4 gives you around about a 32 number deviation from the mean with normally distributed probabilities. Any number is actually possible, but the chance is really small. You should clamp the value if you want it to stay within a certain range.

Link: http://dl.dropbox.com/u/1010927/Forumpics/normalRandomTest.cap

Why do you need loading text exactly?

NormalRandom(mean, sigma)

Generates a random number according to a normal distribution.

<img src="http://3.bp.blogspot.com/_BoiGN8E7WGw/TLdmU21-oVI/AAAAAAAAAFk/ac1TVK0RdQM/s400/Normal_distribution_and_scales.gif">

Mean is the number, sigma is the width of the curve/standard deviation.

Set the animation frame to 1+random(number of frames in animation), every X milliseconds or ticks.

Nice one! But for fog of war an opaque layer (and maybe a PS 0.0 blend mode) with erase objects is probably less gpu hungry. This effect is awesome for lighting effects though, great job.

Looks like irbis has yet to learn a fundamental lesson in gamedev: your creativity is held back by system limitations. Sure, who wouldn't like to have huge images not impact performance? It's not that people don't want it. It's that Construct can't do it. It's hardware accelerated. The engine you used in the past, RPVX or whatever it's called, could not do what Construct can, not even close. Construct is very high performance, but you can't use images of any size; that's the price you pay. Get creative and figure out a way around it. All of these old games that you speak of, they weren't created by spoiled developers who had infinite resources like we (practically) do today. If you were to see the things they had to devise and come up with to get around system limitations, you would leave gamedev forever, as it's a pure technical/mathematical/boring nightmare. Consider yourself spoiled that you can waste resources like crazy and get away with it. So what, you can't use a big image for a space scene. Make some starfield textures, rotate them, overlay them, slap on an additive blend mode, adjust the color filter for infinite color variation, and do the same thing with galaxies; you'll have a starfield which is just as nice, or even nicer than a painted one, at a fraction of the resources use, AND you can animate it, change it, do anything to it with events. More work than drawing? Yes, but that's the price you have to pay to make a game. Anyone who makes games does this. Your not going to get your big image support, it's not something that can just be added. If you want to use Construct, then learn to work around it's limitations, which quite frankly, are few and far between.

Construct is not worst right? i am here not to point that Construct is worst then something. I am just saying that if others can why not to make Construct too be able to handle such features?

I mean, Construct developers are quite a birght minds right? find a way then, you can do it. You are not worst then them right?

It's a different engine, and was made from scratch to accommodate large images. It has different ways of loading them into memory, and the game is structured around loading these images. Construct is an all purpose 2d engine which is hardware accelerated. It doesn't support large images well. And this notion of slicing that you keep bringing up; it only matters if the large image isn't a square power of two. if you have a 2048x2048 image, then no amount of slicing is going to make it use any less resources. it only matters if you have an image which is let's say, 128x2048, in which case the gpu will treat the slices as 16 128x128 images, instead of one large 2048x2048 image. Construct isn't IE. If you want to use large images then section your levels into layouts and load the textures on layout start up, it might work. But in general, you shouldn't design your game around large texture backgrounds, it's not efficient.