One way is to keep track of the velocity. Basically it starts at 0 and accelerates (ease in). Then you can calculate the distance it would take to decelerate to zero and use that the change the acceleration to decceleration (ease out).

Here's a link of the idea:

Thank's rojo. I'll test that out....

Happen to know if there any plugin/behaviour that does the same thing? LiteTween is based on time, not distance, so that wasn't very useful in this case.

Basically a way to apply torque when the distance between mouse and object is far.

Cosine interpolation cosp(a, b, x) maybe

Theres also:

qarp(a, b, c, x)

cubic(a, b, c, d, x)

They are aggressively more complicated however.

Rex has several behaviors that are simpler to implement, moveto, spline, etc.

I've tried both qarp and cubic, but not getting the desired effect.

When mouse left is down, i want the object to accelerate smoothly from 0 to a certain speed based on the distance to the mouse, then when mouse is up I want it to decelerate to zero speed.

using lerp(self.x,mouse.x,0.1) has the desired effect for slowing the object down as it is getting closer to Mouse.X. But the start of the movement is sudden (max speed from start), getting slower and slower as it approach Mouse.X. I don't know how I can smooth out the start of the movement.

I'm basically looking for a curve like this. I know how to do it based on time (but that's not what I'm after), but I don't know how to do it based on distance.

The max speed of the object should be somewhere in the middle.

When i click. I want object to accellerate to a "Max speed" determined by the object current distance to mouse. Max speed should automatically get slower as the object approaches destination (Mouse)

I'm just guessing here.

lerp(a, b, x*m)

X has to be the max speed. (m) The modifier has to be a value, that is pretty close to zero, when the object starts to move and closer to 1 when it's approaching max speed.

a = current position, (not starting position as the mouse can move around)

b = target position, (the current position of the mouse)

x = maximum speed. (the maximum speed)

m = modifier (a value that smoothly scales from 0-1 based on distance where further is closer to 0 and closer is closer to 1)

maybe I'm doing it all wrong, and some math genius here can help me out?

lerp(self.X,mouse.X,0.1) has the desired effect except that the start of movement is snappy not accelerating.

I want the object to smoothly catch up to the mouse current position.

Currently I'm using lerp a lot for smoothing movement (to simulate easeIn/Out. Using a lot of them I'm wondering if there's any good behaviour that does the same thing? I'm guessing that using behaviours are a bit more performance friendly as well.

Any such behaviours available? I tried LiteTween but not doing exactly what i wanted as you has to specify a duration of the tween. I'm more looking for something to constantly smooth things like viewport scrolling, objects that follow the mouse pointers etc.

Any suggestions?

Thanks

I think that 'for each' is a real hog, when having to go trough a lot of objects that need a personal outcome.

So lets do something wild.

https://www.dropbox.com/s/eoxma2kzjj4r4 ... .capx?dl=0

Do you see how i avoid a 'for each' by using a container ?

Interesting. That's quite cool actually, I never thought of that. That might come handy in some cases.

For each is a pain, but sometimes picking just by a variable is enough.

newt On PC yes, but on mobile even 20+ instances can have a considerable effect from what I've noticed. Even using a simple particle emitter is huge NONO for mobile.

Some conclusions I've made so far.

Sprite count on screen is directly related to draw calls. Sometimes fewer bigger sprites is better.

Sprite count is directly related to CPU performance, especially when it comes to picking objects. The more objects you have to pick from the heavier it is.

In this case also, less is more.

99Instances2Go Nice test there. Confirmed my thoughts on what was causing some slowdowns. This is crucial for me especially since I'm developing for mobile. A lot of these small little resource hogs adds up to quite a lot in the end.

So I'm gonna go over my events now and make sure I kill unnecessary stuff. All That don't need to run in the backround.

killing lerps as soon as the get close enough, and not even moving things if I don't have to. I use a lot of lerps happening of screen, things fading in and out etc on the map. I Should try kill those kind of things also. Why do i need to smoothly animate stuff not on screen right?

variable canmove=1 object set position to lerp(newpositions)

On timer set variable canmove to 0

I'll try that too, I just need to stop all the subpixel movements going on.

If something moves at x pixels per second then you can figure out how long it will take to get there if you know the distance there.

Add a timer behavior to change a boolean variable.

Nono, that's not really what I'm after. I just want to stop all the lerping running in the background when they are close enough to see if that's the thing causing some performance issues.

Imagine like 40-50 different objects moving subpixel amounts all the time, because lerp never stops when you use. lerp(self.x, object.x, 0.03) object keeps moving but smaller and smaller subpixel movement every tick.

It's both causing draw calls when everything is seemingly not moving, and ticking away in the background.

You can pick objects by a variable....

Pick by comparison - Object.Variable = 10

Then you can use pickedCount to determine how many were picked and compare it.

Object.PickedCount is between values 1 & (#number you chose) ---- Or Object.PickedCount = 1 - if there's no upper limit.

If 0 is picked will return false.

Pick the 'self' & that 'object'

Compare 2 values .... distance(Pickedself.Y,Pickedself.Y,Object.X,Object.Y) ... > ... 2

______ lerp (dt corrected)

I've tried that but that wasn't really an optimization (for a lot of objects) as it's constantly comparing distances every tick, which seemed to be heavier than just leaving it as it is. There must be a smarter way to limit the amount of decimals.... i don't want all those lerps running in the background all the time.

maybe...

round(self.x) ? round(object.x)

round(self.y) ? round(object.y)

So if both of their rounded X & Y positions are not equal, lerp can bring them closer until their rounded values match.

Should be less heavy to check than distance hopefully. Have to try it out when i get back home from work.

Invisible means its is not rendered.

They should have little performance impact as long as they are invisible, and not moving.

You might get a drop when they are made visible however.

Btw 0 opacity means nothing to cpu performance. It's the same as 100 opacity.

Thanks, I'm trying to pinpoint something causing my draw calls to shoot high occasionally. Even when nothing is seemingly moving and nothing animated is on screen. Clean project doesn't have the problem, so I'm clueless of what it could be.

Although

I'm using a lerp quite a lot, both on objects and on the camera so maybe it could be some objects or the. Checking the Debug, i can see that they are counting down to infinitely smaller and smaller decimal points.

Might be the cause, but how do i stop the lerp from counting?

Example of lerps i'm using.

lerp(Self.X,Object.X,0.03) to get a smooth eased movement...

Maybe there is some better way to ease movements, that doesn't count to infinity?