[jgodfrey]

As a new User, I just wanted to verify my usage of a typical DOTween sequence.  I've have a group of UI buttons that are "stacked" directly on top of each other (so, only the top one is visible).  When the visible button is pressed, I "expand" the underlying stack by tweening each of the buttons to their final, expanded positions.  Here's my basic sequence to do that:

Code: [Select]

        // Create a tween sequence for the Option buttons stack
        _seqOptions = DOTween.Sequence()
            .SetAutoKill(false)
            .SetRelative(true)
            .Join(transInfo.DOAnchorPosY(600, ButtonExpandTime, true))
            .Join(transMusic.DOAnchorPosY(400, ButtonExpandTime, true))
            .Join(transSoundFx.DOAnchorPosY(200, ButtonExpandTime, true));

Then, based on the value of a bool, I play the above sequence either forward (to expand the stack) or backwards (to collapse the stack).  That looks like this:

Code: [Select]

        if (_optionsExpandedState)
        {
            _seqOptions.SetEase(Ease.OutBounce).PlayForward();
        }
        else
        {
            _seqOptions.SetEase(Ease.InBounce).PlayBackwards();
        }

Notice that I have to switch the Ease property based on the direction - to get the same look in both cases. 

All of the above works exactly as intended. However, I just wanted to verify that it's a reasonable solution for what I'm doing.  Thanks for any input/verification you can provide and also for what looks to be a fantastic tweening library.

Jeff

[jgodfrey]

Hmmm... I guess unless someone says otherwise, I'll assume the above-outline is a valid approach.

[vi54]

DoTween is indeed a fantastic tool. I come from a flash background, tested most tween libs for unity and glad to discover DOTween. It feels like what I was using in flash (gsap: or greensock)

I once done it in a similar fashion and got great results.
a recent / current project is doing this aswel.
The only difference is that I most of the time use Switches as for my purposes it seem to perform faster (it's especially noticeable when a lot of things are going on)

But I don't consider myself a pro. It's some research and having hardcore coding friends who often talk nerdish to me
However here's an article that seem to state this too: http://www.blackwasp.co.uk/SpeedTestIfElseSwitch.aspx

Maybe Daniele can confirm this usage for conditionals.

All the best

[jgodfrey]

Hey - the first response drawn by any of my questions...  Thanks for that!

My input on your "if" vs. "switch" dilemma is this...

The speed differences are so negligible that I would never consider one over the other due to speed alone. Even in the tests you link, the results are quite close for a *billion* iterations. Also, I'd bet that the IL generated by a modern .NET compiler for a simple if/else and a 2-element switch are likely identical.

Since I don't think the speed difference is worth considering, I much prefer to code for readability / maintainability. With that in mind, I prefer a simple if/else over the more verbose switch when only dealing with 2 conditions.  However, once the number of conditions grows, I much prefer the look and feel of a switch, so I change to that.