@Ignatz - been fighting with it for a while. At a small angle it looks ok, but as the angle gets wider it seems to move off center. Trying to find out what i’m missing 
if I can’t fix it tomorrow i’ll share the code allready. It must be one of my inputs because the deviation seems to have an identical ratio, not a random deviation
@SkyTheCoder - Thanks, Will try tomorrow as well
Ps: sorry for getting off topic here 
Okay, I got a working example:
-- Path
function setup()
a = 1
b = vec2(0, 0)
t = 0
time = 0
startPosition = vec2(50, 100)
endPosition = vec2(200, 300)
update()
print("Tap in two different spots and see what happens")
end
function update()
distance = startPosition:dist(endPosition)
normal = (endPosition - startPosition):normalize()
end
function draw()
background(255)
stroke(0)
strokeWidth(5)
t = t + DeltaTime
time = t % 1
local p2 = startPosition + normal * distance * time
line(WIDTH / 2, HEIGHT / 2, p2.x, p2.y)
end
function touched(touch)
a = a % 2
if touch.state == BEGAN then
if a == 1 then
b = vec2(touch.x, touch.y)
else
startPosition = vec2(b.x, b.y)
endPosition = vec2(touch.x, touch.y)
update()
t = 0
end
a = a + 1
end
end
Although, after some testing in my efficiency lab (an updated version, I’ll upload it soon I guess), it appears that normalizing a vec2 is nearly twice as expensive as using trigonometry. Huh. I wonder why @Andrew_Stacey told me to use it, then.
@SkyTheCoder In your code, there is no need to use trig or renormalisation. You compute
distance = startPosition:dist(endPosition)
normal = (endPosition - startPosition):normalize()
and use these as
local p2 = startPosition + normal * distance * time
(Minor point: the name “normal” is a bad choice here. Unfortunate conflation of mathematical terminology, but the normal vector is at right angles to the given vector or other object.)
But normal * distance = endPosition - startPosition so you could simplify your computation to
deltaPosition = endPosition - startPosition
and
local p2 = startPosition + time * deltaPosition
Put that in your efficiency lab and see if it improves things.
@SkyTheCoder, @LoopSpace - I’m not sure the code you’re discussing is what the poster wanted. He is not touching two points and interpolating between them.
He is translating to some x,y, then rotating by some angle a, then moving d pixels forward in that direction. His question is what the new x,y position is now. That’s why I suggested a trig solution.
@SkyTheCoder, @LoopSpace, @Ignatz - thank you for the assistance! I’ve tried that code this morning and it seems interesting. I’ll try and incorporate it into my first project tonight.
When I look at that I know my code is far from efficient but I’m still learning I really should start the project from scratch because my code is beginning to be a mess … I messed up once very early and didn’t rename the variable again, so now i need to refer to “endx” and “endy” as my startingpoint and “startx” and “starty” as my ending point just one example of a rookie mistake in my code.
Maybe I should park the code for now and learn Lua some more … but not before I get these coordinates right! I will not be defeated by my own code! \m/
Well, after a few hours of looking at it I’m confident that I made a mistake somewhere at the very base of my script using 3 different calculations to find the center of a sprite under the above conditions, I end up with the exact same deviation on all 3 attempts. the bigger to angle, the higher the deviation …
Rather than looking at where I made a mistake, i’ve decided to recreate the app using the new Lua tricks i’ve learned along the way Many thanks for your insightful answers. I’ve learned a great deal!