64mb RAM, and a 400mhz CPU, honestly? My pc from 15 years ago had more RAM than that, and it had a 333mhz processor, and a 6 GB hard drive.

I'd say the bare minimum is 500 mhz processor, 128mb ram, and some kind of graphics hardware with DX9. Even with that you're pushing it. The event engine bogs down HARD on slower cpus with anything remotely complex. Anything with shaders will also kill framerates on older gpus.

Anything made with Construct needs some kind of graphics card to run at acceptable frame rates. I just don't think a 15 year old pc would cut it.

2. How can you import video into the runtime? You can't without a special plugin or python. You can let the user load music, but what do layouts have to do with that? You can just simulate different "layouts" with proper design, all on a single layout.

It doesn't work well for anything remotely complex, you'll have to make your own.

You learn by practicing, and examining examples.

Sprite2.X - (Sprite2.Width/2)

It means exactly what it says: The X position of the sprite, minus half of its width. It's completely logical, just think about it.

Gblur100 is a powerful 100 sample variable Gaussian blur. It is split into 2 separate shaders to be more efficient. Apply them both for a uniform blur, or just use one if you only want to blur in 1 dimension.

Gblur100 uses -100- Gaussian weighted samples, which means unlike the stock blur shaders (which use 13 samples), this one can blur to extreme amounts, resulting in complete loss of focus, without noticeable quality loss. It is also variable, which mean you can tell it by how much to blur each pixel at runtime.

Moderately new graphics cards won't have any problem handling this shader, but it might be taxing on integrated cards or very old gpu's.

Also included is an oversampling parameter, which makes the blurred image glow or weaken, without using another shader. Useful for transitions, Luminosity level corrections when combining with other shaders, etc.

NOTE: the GIF compression makes the blurring look dithered due to the low color amount, at runtime the effect is completely smooth.

<img src="https://dl.dropbox.com/u/1010927/Forumpics/Gblur100.gif" border="0">

-Download-

If you don't know mySQL and php or an equivalent you can probably forget about an account based system.

Ok, one thing I found was that double clicks don't count as a click. Maybe there's a setting I'm missing, but I created a button, then I wanted a sprite to rotate every time it was pressed down, regardless of if the click was a double click or not. The only action for the button which worked as expected was "on up". I realize there's a seperate action for double clicks, but the button should respond equally for the action "on down" as "on up"

Edit: I experimented further and this only happens if the mouse is pressed at the exact same position as before on the second click. For example, if you change position every time you click, it doesn't care about whether it's a double click or not.

Also, the double click action works strangely, not as expected.

Looks like it could be a godsend for editors made in Construct. Bought a copy, trying it out now!

Basically, It remembers the previous 2 frames, then uses them to affect the data.

Honestly, you're better off trying to recreate the effect yourself by looking at that site, you'll understand the basics and be able to adapt them to your own implementation. Don't feel bad if you don't understand it right away, it's tricky.

However, if you don't know what loopindex is, or aren't experienced in "real programming" (ie, algorithm design, with traditional programming methods) then this might be a bit too complicated to understand for now, but don't let that stop you from trying.

Wow, amazing. One of the few effects that construct was missing.

There isn't a purpose to doing that though, since you want the MaxSpeed variable of the behavior to change according to constantly true events. Where you would modify the real max speed you should just change originalMaxSpeed. If you want to use the actual variable (there isn't really a purpose to this), you should use another eventing paradigm. What that means (basically) is setting up the character with states, so that upon entering "crouched", his max speed changes once (not every frame like it does now), and then it gets set back to the original only once he exits that state. In my experience, this method is much more prone to bugs depending on the complexity of your system. It's much safer coding practice to reset the maxspeed every frame, then change it when things are true. Imagine a waterfall, where game frames are the water. Now, when it flows straight the max speed is its base value. However, when the player is crouched, a funnel diverts the flow of the water to half of it's original value. when the crouching events are true it would set a state "crouched" for the player to 1. Then, whenever crouched=1 it would "create the funnel" (setting the speed to half of it's original). however the frame when crouched goes back to 0 would mean the waterfall returns to it's full force.(the original speed returns.). The reason you would want a state called crouched is so that you can checked whether the player is crouched further down the line for other events. Let's say he can only go invisible while he is crouched, then all you would have to check is if crouched=1, instead of checking whether he is on the ground, and holding down button. Just giving you some insight to a more complex scenario where you would want a solid foundation for more complex logic.

The reason you lose the ability to move is because your dividing the max speed by 2 every frame the condition is true. Max speed is a variable, so when you divide it by 2, next time you access it it will be then halved value, not the original. The reason image-height/2 works is because it's a constant. Had you used .height instead your player would shrink infinitely.

To fix this you have a few options:

1. create a variable called originalMaxSpeed and set it to the max speed you want as a base. Then set max speed to originalMaxSpeed/2.

2. Set the max speed to the base amount every frame, then affect it as the event sheet progresses. Since it will get reset on every frame, then it won't accumulate like it's doing now.

Events don't skip.

Using timedelta is actually the cause of most failed collisions. Using frame based logic will slow down the game when it lags, as opposed to moving the objects further when the frame rate is low. What you have to do to stop collisions from failing is run a loop which steps the objects 1 pixel at a time and checks for collisions incrementally during the loop. For example, if an object is going to move 100 pixels on the x axis this frame, you must run a loop from 1 to 100, and move the object one pixel at a time, and check for collisions after every 1 pixel movement. The loop can also be less accurate (a fixed number of steps moving the object a percentage of it`s required distance each iteration, as opposed to 1 pixel per step), which saves cpu time. This stepping method is how many behaviors work.