Just rehashes of Local Storage solution, got it. Thanks.

It feels like the System object should have a capability to just check if a save slot is occupied. Loading and checking for success/fail is a little inadequate.

Saving using the System object is simple, and so is loading. Apart from saving and loading a separate Local Storage item "DoesSaveExist", is there a way of checking whether a save exists without actually trying to load it?

Bump!

I have that one too. It's quite a problem, actually.

I already tried setting sim. speed rand. to 1000, then, after one tick, to 0, but it gives non-linear spread, because some particles are randomized more than once, and some aren't randomized at all. It's chaotic.

In Particles addon it should be possible to set creation (not only simulation) speed randomiser when the game is already running.

It would help to see a .cap of your objects moving around though.

Sorry, can't do. Secret project They're moving on parabolic trajectories, like in Scorched Earth. If particles' only weakness is lack of control... well, I can live with what I've already done (I've started with particles).

I'm probably going to stick with them, because I found out I can remove original 1x1px sprite and simply move the particle spray. If I find a problem impossible to solve with particles, I'll swich to Sprites.

I'd still appreciate more advice though.

If the number of objects approaches the number of pixels in the screen, you would be better off with plasma.

That's negative.

Particles: probably not a good idea for trails, specially for objects so small

Any particular reason?

Sprites: good if there's much less objects than pixels in the screen, you'd have to do some math to get the trail looking right. Do the objects turn? if so, you'll have to segment your sprites and each segment needs more math. When comparing pixels vs objects, double the number of objects for each segment on your trail, if it's still less than pixels go with sprites.

There are literally dozens of these objects, i.e. max ~2-3 dozens - not thousands. Objects do turn.

Bonus: Lines!

If your objects are 1x1 px, consider using the Line object instead of sprites for the trail. Less vertex data, less computations, faster and simpler to understand. The segment thing goes for lines too, though.

AFAIK, it's even slower than canvas.

I know there were many topics about trails, but this one is quite different. I know how to make trails, but I don't have a clue about their effectiveness. In my application there are dozens of very small (~1x1px) objects with slow-fading trails up to 250 px long and I don't want the app. to lag, even in 1920x1440 resolution. Should I use sprites, plasma, particles or something else?

So far my bet is on particles, but I'm still beginner in Construct.

Was setting R, G or B in Image Manipulator fixed too? Because now it's default to use color selector for it, which crashes application (because most colors don't fit in 0-255). It should be always expression and, if possible, greyscale selector or something.

Well, that doesn't work for me.

http://sourceforge.net/tracker/?func=de ... id=1003219

Oh, well, then it's great I just didn't know it. Thanks!

It'd be very slow, what precise use are you thinking of?

I need visual map that is also an array of 3 low precision integers. Canvas with reading RGB would be best. In Multimedia Fusion there is Overlay object which does that, but I wanted to port my app to Construct. What about second plugin, identical to Canvas but with reading possibility?

You could transfer it to the Image Manipulator plugin and read values using that.

Well, I was hoping that I might use Canvas, as it's faster.