Well just one thing then, I wouldn't use a sprite. Almost any object can have variables, but sprite are drawn objects that you must place, so you could potentially delete it by mistake, and it would just be another object to put somewhere on the side of your layout.

Then I would just use a non world object like array, dictionnary, or anything else that can hold instance variables. You can always call it vars (:

kittiewan

smoke doesn't move faster, smoke is just feet (if you have a running character) or wheels (if it's a vehicle) that creates local air movements and that makes dust fly up... So the faster you go, the more dust smoke you would produce, but the dust doesn't move that much, it just goes up and then fall on the ground.

There's not that much dust going horizontally unless there's a strong friction (like a car stuck in the sand or something like that)

I believe in english that's called a trail

trail2.capx (you can play with randomness values if you want.

Joe7

Yeah you can do that but unless you are super clean and keep track of which index of the array corresponds to which value, it's a pain (:

I always prefer some properly named variables.

Well now... With the Dictionnary plugin maybe... If you're organised such as initializing all the variable you'll use in one place in your event sheet. 'Cause you won't have a list of keys the same way you have a list of global/local variables =)

Basically, once the path is generated, the list of coordinate to go through is stored in an array you can query via getCtXPathList(n) and getCtYPathList(n), n is just the index of the cells listed. It goes from 0 (starting cell) to the the number of cell to travel-1 (the last cell).

But it's just coordinates, if you simply read the array and change the position of the sprite accordingly, you will have a stepped movement.

Lerp(a,b,t) = a + (b-a) * t

so basically if t evolve from 0 to 1 you get a nice interpolation from a to b.

Here I use lerp() to go from index n (a) to index n+1 (b) in the array.

The global variable iteration simply count time since the start of the interpolation.

t = iteration-floor(iteration) means that I only keep the decimal part.

t = 5.2 - floor(5.2) = 5.2-5 = 0.2

So for example, if you are at iteration = 5.5 seconds

You will get something like

Lerp(getCtXPathList(4),getCtXPathList(5),0.5)

Which means you'll be halfway between the X coordinate at n=4 and n=5.

Which also means that if you choose the cut corner option, you'll go faster in diagonal than in orthogonal movements.

This formula can be enhanced by taking into account the distance. But it should be handle at the 'iteration' incrementation. With something like

set length to distance(getCtXPathList(max(0,floor(iteration)-1)),getCtYPathList(max(0,floor(iteration)-1)),getCtXPathList(floor(iteration)),getCtYPathList(floor(iteration)))
set iteration to (length > 0) ? dt*Speed/length : 0[/code:27m508yq]

Well, as there was still some mistake in my capx, I updated it with these new formula and some comments.
And I added a debug text you can set to visible to see how some of the values evolve.

[url=https://app.box.com/s/zo7vfwjpnz4j6g80rajp]kyat-PF.capx[/url]

Nah, no real alternative, I usually use global variable for that.

I already suggested 'Layout Variables' last November but, now that I think about it, it would rather be 'Event Sheet Variables' since each layout can share the same event sheet.

Or some kind of 'static local variable' if it's the right term. Local variable that doesn't get reinitialized.

Anyway, that's Ashley 's call (:

the first animation frame is just empty, and the nine sprites are already created and positionned (snap feature helps for that)

Every 'next' seconds I just set the current sprite to frame 0 (empty) and randomly pick one sprite amongst the eight other sprites and set its animation frame to a random integer between 1 and 20.

the first animation frame is just empty, and the nine sprites are already created and positionned (snap feature helps for that)

Every 'next' seconds I just set the current sprite to frame 0 (empty) and randomly pick one sprite amongst the eight other sprites and set its animation frame to a random integer between 1 and 20.

it can be as easy as this

random9sprites.capx

Building graphically is often heavier on the cpu because you have to handle many object instead of simple numbers in an array.

I did a cave generator some months ago, starting by covering the screen with sprites and mining with 'miner' sprites... it was waaaay slower than the array solution I built afterward.

Anyway here is the thing

mazeBackTrack.capx

Cubemaze uses the Recursive Backtrack algo (:

For a capx hmmm I don't have a basic one right now... Shouldn't be too hard though

Oh I see the resize function does a cropping unless I choose stretch (as it was a noise texture I didn't notice).

But nonetheless, It's still kinda weird to keep the old big collision poly. Maybe it would be better to add another option that says "scale/trim/don't modify the collision polygon accordingly".

I think for most case I would scale it. But it would at least make people aware of what the resize will do.

As we don't see collision polygons by default we might miss the consequence of a resize and come across unexpected bugs.