Jump to content
Search Community

When is relative tweening useful?

Jeremy Rudd test
Moderator Tag

Recommended Posts

Hi all,

 

TweenLite allows relative property tweening if the value is supplied as a string. When is this useful? Apart from the obvious like when you want to move an object offscreen you say "x:10000". But I would still prefer calculating the value absolutely. I simply can't see one real world application for relative tweening. Can anyone tell me if they used it? or where it would be good to use it?

 

Maybe something like this?

TweenLite.to(obj, {x: 50});
TweenLite.to(obj, {x: "10"}); // goes to 60
TweenLite.to(obj, {x: "-10"}); // goes back to 50

Is this a practical example or are there more?

 

Thanks

Link to comment
Share on other sites

Hi Jeremy,

 

I just DID use it. And I did before. Let's say for example you got a game, where you move a stone with the 4 arrow keys. You want the stone to move in a grid kind of area. Every field is X pixels from another. Now you could go and use hardcoded values, because you KNOW the pixel size of each field. But we want to keep things dyncamic for further use or easy design corrections later, so we use the relative movement. We could then say:

 

TweenMax.to(playerStone, 1, {x: ["+=" + fieldWidth] }); // square brackets for creating a String, don't know if necessary.

 

instead of

 

TweenMax.to(playerStone, 1, {x:"+= 20"});

 

and then we never need to touch it again.

 

Did that clear things up?

Link to comment
Share on other sites

Nice ideas, but not exactly. I wanted to know the benefits of relative value tweening vs absolute.

 

Why not use this:

TweenMax.to(playerStone, 1, {x: stone.x + fieldWidth }); // absolute tweening

 

Instead of this:

TweenMax.to(playerStone, 1, {x: String(fieldWidth) }); // relative tweening 

 

Apart from the fact that its "easier" or "prettier" are there any functional benefits to doing it as a string instead of providing the values as absolute values.

Link to comment
Share on other sites

Hi again,

 

I see.

 

TweenMax.to(playerStone, 1, {x: [stone.x + fieldWidth] });
or
TweenMax.to(playerStone, 1, {x: ["+=" + fieldWidth] });

 

The first line would say:

- move "playerStone" to where "stone"s X var is plus fieldWidth

 

The second line says:

- move "playerStone" to where it already is (X) and then add fieldWidth.

 

Nevertheless, I think you wanted "stone.x" to be "playerStone.x" and then it'd probably be the same. Maybe it's a tiny bit faster writing "+=" because you dont need to call the var itself. The "+=" operator does that for you. On the other hand, maybe it takes some time to break up the ["+=" + XYZ] string and calculate/return the final values, instead of doing it directly.

 

But actually I dont think that there are much more differences, so it would not be that different in performing.

 

Hmm... I'd appreciate to get some greensock explanation now, too.

I start feeling a bit unsecure while thinking about your (good) question. Well...did I get your question at all? :)

  • Like 1
Link to comment
Share on other sites

Thanks for trying so hard to help, Lasercode, and welcome to the greensock forums. I'm pretty new here too!

 

The only thing I can think of is elegance and the fact you don't need to calc all the values upfront. So you can chain complex movements and let GS do the rest.

 

- relative : to(pos), to("10") to ("-10")

- absolute : to(pos), to(pos+10), to(pos)

 

I can't really tell which is better.

Link to comment
Share on other sites

Yeah...maybe I got my head above the parapet. But all this new stuff (I'm also on arduino combined with flash atm) really keeps me awake at night and I am so damn interested, that I feel like a child on coke that just met God.

 

I'll keep my energy back a little from now on. No one needs posts without solutions. That makes this forum so good.

 

Btw: I think you post really good questions, as I read some of them before. Keep it up. I learn much from it.

Link to comment
Share on other sites

The answer you are looking for is convenience. Plain and simple.

 

There are thousands of people using Greensock of all different skill levels, and things like relative tweens, which to you might seem like unnecessary bloat since you can work it out yourself, can be a great convenience to others. Greensock is about performance first and foremost, as the benchmarks will surely show you, but when convenience methods like relative tweens can be had cheaply, why not offer them to those that want them? There is no benefit at all to the engine speed, although the speed cost would be so negligible it probably wouldn't be worth measuring. The memory and CPU cost to do the step from relative to absolute tween inside Greensock as opposed to pre-calculated would be thoroughly insignificant (if there even is one).

 

And to offer an alternate view to what you've said:

TweenMax.to(playerStone, 1, {x: stone.x + fieldWidth }); // absolute tweening

is not a great example of absolute tweening, since working out the x value this way is exactly what relative tweening involves. Just because you've manually done the step of working out the absolute value from a relative one (my_position + relative_value) doesn't make it 'not a relative tween'.

 

e.g.

- object at x:0

Tween object to x:100, then x:500, then x:1000 // absolute tweens

Tween object to x:object.x + 100, then x:object.x + 400, then x:object.x + 500 // pre-calculated relative tweens

Tween object to x:"+=100", then x:"+=400", then x:"+=500" // relative tweens

 

The only important difference is how individual programmers would prefer to create their tweens.

 

 

EDIT: Well it seems there are actually some very functional reasons for relative tweens as well. I stand corrected.

Edited by jamiejefferson
  • Like 3
Link to comment
Share on other sites

Here's an easy example of when relative tweening is absolutely essential:

 

Let's say you've got a bunch of TextFields on the screen and you want to animate them into place, dropping from 100 pixels above wherever they are...

 

//all y values actually end up unique
TweenMax.staggerFrom([tf1, tf2, tf3, tf4], 1, {y:"+=100", ease:Elastic.easeOut}, 0.1);

 

Without the relative value, you'd need to loop through each element in the array and create a new tween.

 

Another key reason is for scheduling tweens in the future (Jamie touched on this). Your sample code assumes that the tween is starting NOW, so you're reading the current object.x but what if there are other factors in your app that could affect object.x and you just want a tween to start moving it 100 pixels to the left of wherever it happens to be at that time? Without relative tweens, that would be impossible.

 

Make more sense now?

  • Like 3
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...