I am using this code to animate a sprite (Player inherits the Sprite class):
function Player:moveIntoPosition()
local lineIntoPosition = geo.lineSegment.new(150, 250, 200, 120)
local anim = gfx.animator.new(1500, lineIntoPosition, pd.easingFunctions.inOutBack, 250)
self:setAnimator(anim)
end
This code generates the following error
Update error: CoreLibs/sprites.lua:197: bad argument #1 to 'moveTo' (playdate.geometry.point expected, got nil)
stack traceback:
[C]: in method 'moveTo'
CoreLibs/sprites.lua:197: in function <CoreLibs/sprites.lua:191>
[C]: in field 'update'
main.lua:35: in function <main.lua:34>
If I replace the easing function by linear (I also tried a few others), I do not get the error.
Hi @matt, the bug you mentioned hints on a compiler issue for -=. Nonetheless, this snippet does not use it, and the inOutBack easing function does not look like it is using it as well. I am not sure they are related.
Here is a code snippet containing a commented code that works (linear) and the one which doesn't (inOutBack). I haven't tried all easing functions but noticed this is not the only one with this issue.
import "CoreLibs/object"
import "CoreLibs/graphics"
import "CoreLibs/sprites"
import "CoreLibs/timer"
local pd <const> = playdate
local gfx <const> = playdate.graphics
local geo <const> = pd.geometry
local Animator = gfx.animator
local ls = geo.lineSegment.new(50, 50, 325, 90)
-- Works
-- local lsAnim = Animator.new(1000, ls, pd.easingFunctions.linear, 1000)
-- Doesn't work
local lsAnim = Animator.new(1000, ls, pd.easingFunctions.inOutBack, 1000)
local r = 10
local imgCircle = gfx.image.new(r * 2, r * 2)
gfx.pushContext(imgCircle)
gfx.fillCircleAtPoint(r, r, r)
gfx.popContext()
local spriteCircle = gfx.sprite.new(imgCircle)
spriteCircle:moveTo(50, 50)
spriteCircle:setAnimator(lsAnim)
spriteCircle:add()
function pd.update()
gfx.sprite.update()
end
Looks like I added that bug when I fixed some others recently. Here's a patched CoreLibs/animator.lua: animator.lua.zip (2.2 KB)
I never noticed that we constrain geom.lineSegment.pointOnLine() to within the segment endpoints.. Kind of ruins inOutBack and the other underdamped easing functions. I'll file that.
With this fixed I notice the underdamped functions like inOutBack don't overshoot the end and bounce back like they're supposed to, because the lineSegment:pointOnLine() function constrains the returned point to between the segment's endpoints. Seems like a bug to me, though fixing it introduces a behavior change.
My feeling is nobody's relying on the current behavior, it's so obviously broken. But maybe I'm wrong? Any thoughts?
I am thinking the same honestly. While the code compiles, it didn't really behave the way I was expecting (event the speed seemed off when I look at the example I provided).
The behavior change is a bit tricky to handle. Do you know when the compilation bug was introduced? This could help in better understanding how much this function is actually used. You said 'recently' but if the bug had been there for a while, I am thinking "Just fix it".
Otherwise (recent regression), I guess we just reverted to the old buggy behavior, but some games may be relying on it... In this instance, we could either do a quick survey but not sure it would reach enough people.
If I were in your position, I would actually fix the behavior and have a fallback plan (such as a boolean as a last parameter to allow the calculation outside of the segment's points) if there are some complaints...
The change in behavior could be explained in the RN but it should not break the games so I'd go for this.
I added an optional "extend" flag to the lineSegment:pointOnLine(), arc:pointOnArc(), and polygon:pointOnPolygon() functions which stops the function from constraining the returned point to the path, and added that flag to those calls in CoreLibs/animator.lua. Feels like this is the right behavior:
Here's a patched CoreLibs/animator.lua: 
