Genesys: Of course sin and cos are used. Lucid just wanted to know if there counstruct was using some GPU-optimised method with image points, as he wanted to optimise his own code for speed.

Yeah, I'm surprised too, is there really that much of us? :P

One would call this a spline; a path which consists of many lerped or quarped curves. (In theory, it would be possible to use higher order bezier curves, but this takes more computing power than splines, and the control points don't effect the curve so easily.) It would be nice feature to have, but I think it could be bundled into path behavior, it has the same kind of functionality.

I love my DS, it has lots of fun games to play. And if your friends have DSs too, it gets a ton more entertaining. For example, Mario Kart WiFi with 8 players - pure awesomeness.

What you are actually trying to do? If you are setting objects to move to 16 pixels below themselves, they shouldn't stop either, as they don't stop with lerp. If the condition keeps evaluating true, the actions will happen again an again.

Yes, that indeed would work.

But only when using one outline. If you wanted to build a labyrinth using many tunnel sprites and their outlines, the outlines would block the character from moving from one tunnel to another in an intersection.

> With what event's?

>

you must have missed what was said. Ready Mipey's post

No, I didn't miss what was said. The method suggested doesn't work the same way as proper solution would. "Is overlapped by passable" is different from "is totally covered by passable".

Imagine that there is a mountain and a tunnel. With "overlapping passable" the character could move inside a solid rock wall, if it overlapped "passable" by just one pixel. If there would be "is totally covered" condition (= There isn't ANY pixel which DON'T overlap), it would be possible to do correct way - so that character couldn't overlap the solid rock at all.

With what event's? It is already stated that you can do it with canvas, but that solution wasn't too perfect.

you can:

Oh, I see. I'm embarrassed to say that I have clearly used canvas object too little :P

If I understand correctly, you just want an attribute that undoes 'solid' and makes its opaque area count as non-solid space?

I'm not sure using hundreds of anti-solid sprites for destructible terrain is a good idea performance-wise - it might be better just to use lucid's suggestion, especially given it could be tricky to program an antisolid attribute.

There is another things you can do with this too. And it isn't possible to create simple moving and resizing etc. holes in solid with canvas. Say you want to have liquid, where the character can't go, but there's bubbles in the liquid, and the character can move inside these bubbles.

Also, I can think uses for is fully overlapped/covered/whatever by ... -condition. Is it hard to do? For Construct 2, at least?

if 'object overlaps solid object'

(negated) 'overlaps nonsolid object'

Yeah, but that isn't same. With "Overlaps nonsolid" (Though I prefer antisolid, it's clearer way to say it) collision event triggers only when the sprite doesn't overlap tunnel at all, but collision event SHOULD trigger when even PART of the sprite is not overlapped by nonsolid. In another words, the condition should be "(negated) totally covered by nonsolid object". And we don't have this kind of condition.

That "totally covered by" would be nice feature to have also... the collision checker wouldn't search for pixels which collide, but pixels which DON'T collide.

So, you're talking about... like "un-solid" or "anti-solid" mask. If the force field overlaps a solid block partially, say, it overlaps the upper part, but not the lower part, only the lower part would act as solid, since the anti-solidness would cancel the solidness of upper part of a block.

So, it would would work like mask - but it would mask the collision mask, not graphics. And it would indeed be useful for destroyable terrain, or let's say that you have a solid object "mountain" and then you place antisolid "tunnel" on it, and the antisolidness masks off the solidness of the mountain - and you can move in the tunnel, but not elsewhere in the mountain.

I think it's a really useful feature to have, but the problem is, how easy it is to implement technically. I think the devs could say something about that :)