That’s kinda what I meant with calculating. You’d effectively be just doing all the math that mouse.x/y does behind the scene. Which would work but I don’t think it provides much benefit.
As for the lagging of the sprite behind the actual mouse cursor. I thought that was just because of latency between code and the drawn frames or 1/60th of a second.
An alternative is the to set the mouse cursor from a sprite, which doesn’t lag behind but it’s on top of everything as it’s not truly a sprite then. That reason that doesn’t lag is the operating system is drawing it then which is more input event based instead of frame based.
Anyways unless the lag you’re seeing is something different. In which case I’m all for tightening it up if possible.
It just occurred to me that when you scroll some stuff doesn’t get recalculated till the end of the tick. For example viewportLeft(). It possibly could be the same for the mouse(layer).x expression. That could be lag you’re getting which is different than the other one I mentioned.
You’ll have to test it but assuming that that setting the scroll position causes mouse.x to update till the next tick you can order your events like this.
Basically before scrolling, save the scroll position to variables. Then after the scroll correct the position.
Set sprite x to mouse.x
Set oldScrollx to scrollx
Set scroll position
Set sprite x to self.x-oldScrollx+scrollx