[SOLVED] Using Lua Easing Functions without Transition

Solar2D General Questions/Discussion
#1

Hi,

I want to use easing functions but the way my game is built, I cannot use the built in ones. In my game, the player can move while an easing function is triggered on them and using a transition on the player object prevents the user from moving for that brief moment. So I went with the path of using deltaPerFrame and I want to apply easing functions on the player’s x motion.

I am looking at this Easing Library on Github and trying to make use of it. Now in my game let’s say the player is at x = 480px, they hit an object and I want to move them back 100px in the duration of 100ms. So their ending would be x = 380px.

Here is a visualization of what I’m trying to do:

Here are my variables (let me know what I’m doing wrong)

t = 0 -- Need to increment this from 0 to duration b = player.startX player.endX = player.startX - 100 c = player.endX - player.startX d = 100 -- milliseconds outExpo(t, b, c, d) -- Need to call this function repeatedly until t reaches d

I tried using a performWithDelay call but I’m getting unexpected results.

#2

Shouldn’t you be doing this in an Runtime enterFrame listener?

Rob

#3

That’s what I original thought to do too but then I ran into the issue of how to increment the time (t)? I tried to increment it by 1 or 1/60 but it didn’t work.

I’ll take another go at it and share my results with that attempt. Thanks Rob.

#4

I second Rob, the best option besides the easing library is an enterFrame listener for the Runtime.

What type of easing would you like to do? Easing in, out, or in and out? Exponential or quadratic?

One really easy type of easing I used to do back in the old days was move my objects by half the distance between the current position and the end position. Code is the something like this, running each frame (so in an enterFrame event):

local xIncrement = (xEndPosition - player.x)/2

player.x  = player.x + xIncrement

(and same for Y axis)

Note that the above formula does not require a time parameter. The time is just fixed to “one frame”. It’s a simplified approach, but works well enough for 99% of my work.

This results in a fast starting “snappy” kind of movement - with half the total distance covered in the first frame. This worked great for interface elements to quickly move into place, but for game mechanics it might be too fast…

It’s of course really easy to tweak the formula above. Tweaks could include:

  1. Dividing by more than 2 for a slower easing.

  2. Dividing by more only adjusts the ending of the easing. The start will still be pretty abrupt. If you want to make the starting movement more fluent, you can add limiting factors like friction or velocity.

performWithDelay is much to noisy and finicky to use for this purpose.

#5

I just thought to myself that I would probably just create a hack method :smiley:

For instance, you can’t move the player with a transition, but how about some invisible on or off the screen rect? Consider this. You create a new rect, let’s call it “tRect”, and you set its visibility to false so that it’s always out of sight. Now, you create a Runtime enterFrame listener that does exactly two things:

  1. Calculate delta X and Y for tRect
  2. Add the delta X and Y to the player’s X and Y.

Finally, just apply the transitions that you want on the tRect. It doesn’t matter where the tRect ends up as its only function is to be moved around by transitions. This way, regardless of what the player is doing or how their character is controlled, they’d be influenced by the transition exactly as if they’d be experiencing it.

Lazy hack coders, huzzah! :smiley:

#6

For the record: violently hitting an object and being pushed back, much like hitting a bumper in a pinball machine, would work perfectly with my above code.

#7

Shouldn’t you be doing this in an Runtime enterFrame listener?

Rob

#8

That’s what I original thought to do too but then I ran into the issue of how to increment the time (t)? I tried to increment it by 1 or 1/60 but it didn’t work.

I’ll take another go at it and share my results with that attempt. Thanks Rob.

#9

I second Rob, the best option besides the easing library is an enterFrame listener for the Runtime.

What type of easing would you like to do? Easing in, out, or in and out? Exponential or quadratic?

One really easy type of easing I used to do back in the old days was move my objects by half the distance between the current position and the end position. Code is the something like this, running each frame (so in an enterFrame event):

local xIncrement = (xEndPosition - player.x)/2

player.x  = player.x + xIncrement

(and same for Y axis)

Note that the above formula does not require a time parameter. The time is just fixed to “one frame”. It’s a simplified approach, but works well enough for 99% of my work.

This results in a fast starting “snappy” kind of movement - with half the total distance covered in the first frame. This worked great for interface elements to quickly move into place, but for game mechanics it might be too fast…

It’s of course really easy to tweak the formula above. Tweaks could include:

  1. Dividing by more than 2 for a slower easing.

  2. Dividing by more only adjusts the ending of the easing. The start will still be pretty abrupt. If you want to make the starting movement more fluent, you can add limiting factors like friction or velocity.

performWithDelay is much to noisy and finicky to use for this purpose.

#10

I just thought to myself that I would probably just create a hack method :smiley:

For instance, you can’t move the player with a transition, but how about some invisible on or off the screen rect? Consider this. You create a new rect, let’s call it “tRect”, and you set its visibility to false so that it’s always out of sight. Now, you create a Runtime enterFrame listener that does exactly two things:

  1. Calculate delta X and Y for tRect
  2. Add the delta X and Y to the player’s X and Y.

Finally, just apply the transitions that you want on the tRect. It doesn’t matter where the tRect ends up as its only function is to be moved around by transitions. This way, regardless of what the player is doing or how their character is controlled, they’d be influenced by the transition exactly as if they’d be experiencing it.

Lazy hack coders, huzzah! :smiley:

#11

For the record: violently hitting an object and being pushed back, much like hitting a bumper in a pinball machine, would work perfectly with my above code.