Using this code:

**Spoiler:**show

...But that doesn't matter too much to most people. What really matters (at least when you're not using LunaLua) is the timing on moving layers.

I measured the number of ticks between a pair of events triggering each other on a given delay, causing a block to move up and down. As expected, at speed 1 the block moved the same distance as the number of ticks (speed being measured in pixels per tick, where a block length = 32 pixels). The number of ticks, however, turned out strange:

**Spoiler:**show

Natsu said in this thread that, effectively, the distance moved is speed*time*65. This is pretty close, but you can't have a fraction of a tick. The number of ticks for a given number of seconds appears to be:

(seconds*65)+1, rounded to the nearest ODD number if it ends in .5

Normally .5 is rounded to the nearest even number, but presumably it's rounded before the 1 is added, resulting in it rounding towards odd numbers instead.

In that case the distance moved is:

speed*((seconds*65)+1, rounded to the nearest ODD number if it ends in .5)

The extra 1 is what tends to throw off the timing of layers. For example, a speed of -1 for 2 seconds and a speed of 2 for 1 second moves the layer -131 and then +132, causing it to go further off by 1 each cycle.

However, moving it by -1 for 1 second and +2 for 0.5 seconds does work because the number of ticks for 1 second is twice the number for 0.5 seconds. Another solution is to split up the first delay, so you have the layer moving -1 for 1 second, then -1 for 1 second again, then +2 for 1 second.

It's all in how the ticks add up. I hope this is helpful!