You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The project I'm working on had GC allocation issues caused by DOTween. These came from newly created tweens' allocations (can be reduced via tween pooling) and tween callbacks' closure allocations. PrimeTween has been very helpful while eliminating those allocations, so thank you. The additional free performance gain is also very much welcome.
I had some mental and practical difficulties during the transition and I wanted to share them. Not all of them have solutions, of course.
I wish Sequence naming convention was similar to DOTween and LitMotion: Append instead of Chain and Join instead of Group. It'd be nice to have them implemented in here as well (they can call Chain and Group with the passed parameters directly)
I want to be able to add a target to a Sequence so that if target is destroyed, the whole Sequence is automatically stopped
It'd be nice to be able to store Tween and Sequence in the same variable type. For DOTween, that common type is Tween. For LitMotion, if I am not wrong, that type is MotionHandle. I have a Tween variable that I can stop when something happens but that Tween can sometimes be a Sequence. My current solution is changing Tween to Sequence and creating a Sequence even for the cases that require a single Tween
This is already discussed but Tween.OnKill would really be useful in some cases. For example, I have a Tween that rotates a target indefinitely. I can stop it from multiple locations. When the Tween is stopped, I want the target to reset its rotation to a particular value. At the moment, I need to create a wrapper function around rotationTween.Stop which is not always as convenient as OnKill. Another use case is, I'm blocking UI input while a UI tween is running. I'm unblocking the input after the tween is completed. But I want to unblock the input if the tween is killed/stopped early, as well. This particular scenario IMO is very hard to implement without OnKill
I like Tween.Delay as GC-free alternative to DOVirtual.DelayedCall but if I pass a target to Tween.Delay, if I understand the XML comment correctly, the callback won't be invoked if the target is destroyed early. However my intention of passing the target isn't to stop it early but to avoid the allocation cost of the callback. So I'd like the target object to not stop the Delay if it's destroyed
I wonder what happens if a Tween's target object is destroyed and the Tween is inside a Sequence. Will the Tween immediately be skipped?
I think I prefer the fluent interface pattern that DOTween and LitMotion uses. I've also seen this mentioned in git-amend's LitMotion video. I'm especially struggling when I want to pass a startValue to my Tweens because then without the startValue:x endValue:y syntax (explicitly naming parameters which I rarely use), it becomes confusing with endValue:x duration:y
I was using DOTween.From's setImmediately parameter extensively while animating panel transitions in a Sequence and moving UI elements outside the screen immediately (they enter the screen during the Sequence)
I was actually more inclined to use LitMotion since my project already uses Job System and Burst Compiler and I prefer explicitly binding objects to the Tween's lifetime (DOTween's SetLink and LitMotion's AddTo method). However having to set the startValue explicitly for every Tween was not possible in my case. I'm still happy with PrimeTween
It'd have been nice to be able to install the package directly from git URL
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
The project I'm working on had GC allocation issues caused by DOTween. These came from newly created tweens' allocations (can be reduced via tween pooling) and tween callbacks' closure allocations. PrimeTween has been very helpful while eliminating those allocations, so thank you. The additional free performance gain is also very much welcome.
I had some mental and practical difficulties during the transition and I wanted to share them. Not all of them have solutions, of course.
rotationTween.Stopwhich is not always as convenient as OnKill. Another use case is, I'm blocking UI input while a UI tween is running. I'm unblocking the input after the tween is completed. But I want to unblock the input if the tween is killed/stopped early, as well. This particular scenario IMO is very hard to implement without OnKillstartValue:x endValue:ysyntax (explicitly naming parameters which I rarely use), it becomes confusing withendValue:x duration:ysetImmediatelyparameter extensively while animating panel transitions in a Sequence and moving UI elements outside the screen immediately (they enter the screen during the Sequence)All reactions