I was reminded by a recent post in the forum that the calling convention for Corona’s easing functions isn’t well-documented. It’s fairly easy to “reverse-engineer” by experimenting, if you’re at all familiar with Robert Penner’s easing equations, and doing so will allow you to potentially create your own custom easing formulae.

At some point the subject should be treated with more depth, but I’m not feeling particularly ambitious today. 😀 So without further ado, here’s the aforementioned function:

1 2 3 4 5 6 7 |
local function inOutCubicOvershoot(t,tmax,start,delta) -- mimics "inOutBack" local s = 2.6 -- overshoot factor, alter to suit (see below) local icurve = function(t) return (s+1)*t*t*t-s*t*t end local ocurve = function(t) return 1-icurve(1-t) end local iocurve = function(t) return (t<0.5) and icurve(t*2)/2 or ocurve(t*2-1)/2+0.5 end return start + iocurve(t/tmax) * delta end |

Note that this function probably doesn’t exactly duplicate Corona/Penner, so I renamed it to avoid “claiming” that it did. Still, it’s mathematically very similar.

For readability, I’ve left it unoptimized to reveal its internal workings and 2t^3-t^2 origin — you can refactor and optimize further as you like. As written, it’s (intended to be) useful as a test-bed for developing new curves – just alter the icurve() function. Once you understand how all the “parts” work together, then you can inline all those unnecessary function calls.

The component in and out curves are in there as well, so if you don’t want the inOut version then just replace the call to iocurve() in the return statement with either icurve() or ocurve(). (or create separate versions of all three)

Test it like this:

1 2 3 4 5 6 7 |
-- Corona's, for reference local rect1 = display.newRect(100,100,20,20) transition.to(rect1, { time=3000, y=400, transition=easing.inOutBack }) -- the new one, for comparison local rect2 = display.newRect(200,100,20,20) transition.to(rect2, { time=3000, y=400, transition=inOutCubicOvershoot }) |

Now, for the fun part: See that “s = 2.6” in there? That’s what controls “how much” overshoot occurs, and the 2.6 gives it about a 10% overshoot. If you’d like less overshoot, then reduce the value of s; if you’d like more overshoot, then increase the value of s.