Smooth for me, card did get to work though (fan spinning faster).

AMD 2.5 Quad

Radeon HD4870

4Gb RAM

placing tiny objects in a monster layout isn't very comfortable anyway.

You could place objects using an editor (made by yourself) that creates a text file with the data.

Or, you could generate positions randomly.

if it's this, the other day I was just pondering if there was a nice, comfortable solution for this.

I've seen even commercial games make this mistake and anything I can think of so far is cumbersome (say, you want something to happen when 3 buttons at the same time? that'd be 9 events)

Perhaps a finite state machine would help, come to think of it....

On Key Release works fine for me. Made a .cap to play a sound on space released and it did just that.

Can we have On Control Release too?

That would be like Construct's built in blur, a kind of effect which is not even done for feature films . They use postprocessing with velocity buffers, which in 2D yield the same speed for a whole sprite UNLESS ITS ROTATING.

So... this should be good enough except for the rotation case, which I'm thinking about but can't quite come up with a nice effect for it

It's hard to notice the details in fast moving objects so don't worry about velocity changes between frames. Physically accurate blur shouldn't be larger than the distance travelled by the sprite in screen space, so you couldn't tell the difference anyway.

Oh yeah and I overdid the blur size hit the bounding box, didn't notice that. Size is bounded by Construct.

If you want the trail particles to live longer than its "master", you could set a private variable in each of them with the UID of the "master", then when a "master" object dies you would look up their children comparing their private variable with the UID of the dying "master" object and set off a timer behavior to kill it later.

Doing so would kill the whole trail at the same time but a little while after the "master" dies.

Of course, you could also have the timer event set off timers for other children, in which case you can arrange some pretty complex dying orders just storing the proper UID in the proper particle.

JPG does save in distribution size though. I could easily see myself doing that.

Why would one want to use lossy jpgs? well, the same reason the whole world uses it as the primary image distribution format

Come to think of it... I'll probably do it too I have a game that will use big backgrounds and I don't want the distribution getting all huge because of that.

Won't make a difference performance-wise though, except at image load time.

Adjustable-size motion blur. Good for speeding objects.

Use two times in perpendicular angles (0 and 90) to get adjustable-size gaussian.

(called blur motion instead of motion blur so it will sit neatly in the list next to the other blurs )

Thanks for the comments, guys. By the way, I'm just wondering, would anybody rather see the speed in degrees-per-second?

That could be useful, but the current speed setting (in px per second, I assume) is also useful. Can we have both?

I guess you could hack the produced exe and add menus from there

Just the loading time, once loaded its the same as normal.

If you're loading a lot of images you could do a progress indicator.

Nice, I'm looking forward to play it