What is the logic behind easing.continuousLoop?

[dmglakewood]

When ever I use easing.continuousLoop I have do double all my values. For example if I want to scale the image twice as large instead of doing yScale=2, xScale=2 I have to do yScale=4, xScale=4. Or if I want to move the image to 100,100 I have to do x=200, y=200. I’m just wondering what the logic is behind this so I can maybe understand it better.

In my mind it should work the exact same as transtions do normally just it returns to the original object. So if you do xScale=2 it should scale twice as large then return back to normal. Everytime I use easing.continuousLoop I’m very confused when something isn’t working only to realize that I didn’t double my value.

[davebollinger]

there is no logic it’s buggy, for example try this:

local ref1 = display.newLine(100,0,100,300); ref1.strokeWidth=2 local ref2 = display.newLine(300,0,300,300); ref2.strokeWidth=2 local box1 = display.newRect(100,100,20,20) local box2 = display.newRect(300,200,20,20) transition.to(box1, { time=1000, x=300, transition=easing.continuousLoop, iterations=-1 }) transition.to(box2, { time=1000, x=100, transition=easing.continuousLoop, iterations=-1 }) -- each box SHOULD move back-forth to exactly each ref line, but nope

it’s weird too, because if you call easing.continuousLoop yourself and dump out the values, you’ll see that it does return a perfect “sawtooth” wave as expected, so it’s perhaps some weird interaction with transition lib that’s causing it (not the easing function itself).

…at any rate you’re better off using onComplete to ping-pong between two opposing linear transitions instead

[dmglakewood]

@davebollinger

there is no logic it’s buggy, for example try this:

local ref1 = display.newLine(100,0,100,300); ref1.strokeWidth=2 local ref2 = display.newLine(300,0,300,300); ref2.strokeWidth=2 local box1 = display.newRect(100,100,20,20) local box2 = display.newRect(300,200,20,20) transition.to(box1, { time=1000, x=300, transition=easing.continuousLoop, iterations=-1 }) transition.to(box2, { time=1000, x=100, transition=easing.continuousLoop, iterations=-1 }) -- each box SHOULD move back-forth to exactly each ref line, but nope

it’s weird too, because if you call easing.continuousLoop yourself and dump out the values, you’ll see that it does return a perfect “sawtooth” wave as expected, so it’s perhaps some weird interaction with transition lib that’s causing it (not the easing function itself).

…at any rate you’re better off using onComplete to ping-pong between two opposing linear transitions instead

I was wondering if it was a bug but figured as noticeable as it was it would have been fixed by now. So then I started thinking there was a reason behind it but I guess not. It’s useable as long as you realize that everything has to be either half or double what you want it to do.

[davebollinger]

there is no logic it’s buggy, for example try this:

local ref1 = display.newLine(100,0,100,300); ref1.strokeWidth=2 local ref2 = display.newLine(300,0,300,300); ref2.strokeWidth=2 local box1 = display.newRect(100,100,20,20) local box2 = display.newRect(300,200,20,20) transition.to(box1, { time=1000, x=300, transition=easing.continuousLoop, iterations=-1 }) transition.to(box2, { time=1000, x=100, transition=easing.continuousLoop, iterations=-1 }) -- each box SHOULD move back-forth to exactly each ref line, but nope

it’s weird too, because if you call easing.continuousLoop yourself and dump out the values, you’ll see that it does return a perfect “sawtooth” wave as expected, so it’s perhaps some weird interaction with transition lib that’s causing it (not the easing function itself).

…at any rate you’re better off using onComplete to ping-pong between two opposing linear transitions instead

[dmglakewood]

@davebollinger

there is no logic it’s buggy, for example try this:

local ref1 = display.newLine(100,0,100,300); ref1.strokeWidth=2 local ref2 = display.newLine(300,0,300,300); ref2.strokeWidth=2 local box1 = display.newRect(100,100,20,20) local box2 = display.newRect(300,200,20,20) transition.to(box1, { time=1000, x=300, transition=easing.continuousLoop, iterations=-1 }) transition.to(box2, { time=1000, x=100, transition=easing.continuousLoop, iterations=-1 }) -- each box SHOULD move back-forth to exactly each ref line, but nope

it’s weird too, because if you call easing.continuousLoop yourself and dump out the values, you’ll see that it does return a perfect “sawtooth” wave as expected, so it’s perhaps some weird interaction with transition lib that’s causing it (not the easing function itself).

…at any rate you’re better off using onComplete to ping-pong between two opposing linear transitions instead

I was wondering if it was a bug but figured as noticeable as it was it would have been fixed by now. So then I started thinking there was a reason behind it but I guess not. It’s useable as long as you realize that everything has to be either half or double what you want it to do.