GreenSock


Licensing: “Free” != Better

Posted in Tweening by jack on the June 25th, 2009

Open source projects are great. Many provide elegant, refined code for free. They can save hours of development time and hassle. They’re often a jumping-off point for up-and-coming developers to share their innovation with the rest of the community, inspiring others to write better code. Of course there are also plenty of open source projects that are riddled with bugs, poorly documented, and downright dangerous to use. The web is littered with abandoned projects that once seemed promising. It’s like a clearance bin you’d find at a discount store – there may be some treasures in there, but you’ll have to dig through a lot of garbage to find them.

Over the years, I’ve seen quite a few open source tweening engines pop onto the scene, get some buzz, and then gradually stagnate and fade off the scene. Many stay in Beta for ages. Some contain known, unpatched bugs. The community usually does a good job of eventually recognizing quality solutions and gravitating towards them, but there are always people who try out the “latest and greatest” thing, only to be disappointed in the end as it stagnates or fails to mature. My goal has been to figure out a way to protect the GreenSock tweening platform from falling victim to the common frailties of open source projects. I have learned that one of the key factors in keeping a project thriving is actually the licensing model.

More...

Last Call for v11 Input

Posted in Tweening by jack on the April 30th, 2009

Before officially releasing v11 of the GreenSock tweening platform, I wanted to solicit feedback from the community one last time, particularly on TimelineLite/Max because after the API is locked down, it’s pretty tough to change. Here are the specific questions I’d like feedback on (please feel free to offer feedback/suggestions about topics that aren’t on this list too):

  1. 1) TimelineLite & TimelineMax – how does the API “feel”? – Does it give you the power and flexibility you need without being bloated? Have you found yourself needing some kind of functionality that’s missing? Is everything intuitive?
  2. 2) Should ALL plugins be activated in TweenMax by default? – I haven’t done so because I’m afraid it may be seen as “bloated” with the extra kb. On the other hand, it’s not terribly difficult to open the class file and prevent activation of certain plugins if you need to conserve file size, and activating all plugins would prevent some potential confusion for newbies. Keep in mind that there will likely be more and more plugins over time that offer added functionality, so if they’re all activated, TweenMax may hit 30kb at some point in the distant future.
  3. 3) Should I eliminate the default plugin activations in TweenLite? – This would cut the default file size by around 40%. When I asked this question in v10, I got a fair amount of feedback saying backwards compatibility was much more important than small file size, especially because end users could delete the activation code inside the class file if they needed smaller file size. Then again, TweenLite is supposed to prioritize small file size and a lot of end users are either scared to or don’t understand how to delete the activation code in the class file.
  4. 4) Are there any important features missing? – I’m trying to prevent bloat while at the same time provide tremendous flexibility, power, and speed. It’s a balancing act. Let me know if you were really hoping a particular feature would make its way into one of the classes.
  5. 5) What is your favorite feature (or features) that absolutely, positively shouldn’t get cut? – I’m not fishing for compliments here – it’s just helpful to know what the community values so that those features don’t end up on the cutting room floor (so to speak).
  6. 6) Should “repeat” be renamed “cycles”? – “repeat” seems more common, but some have suggested that “cycles” is more intuitive. If it gets changed to “cycles”, what would you name “repeatDelay”?
  7. 7) Should append() and prepend() be eliminated from the timeline classes? – One developer suggested eliminating append() and prepend() because they’re not absolutely necessary. For example, append() could be accomplished with myTimeline.insert(myTween, myTimeline.duration). prepend() is more difficult, though. Personally, I find them very intuitive for building sequences and they don’t cost much kb.

If you haven’t tried v11 yet, especially the TimelineLite and TimelineMax classes, I’d highly recommend it.

More...

GreenSock Tweening Platform v11 Beta (Introducing TimelineLite/Max)

Posted in Tweening by jack on the April 10th, 2009

On the heels of releasing the huge v10 update that introduced the plugin architecture, I’ve been hard at work on an even bigger release that delivers quite a few exiting improvements to the GreenSock Tweening Platform. Version 11 represents some significant changes to the guts of the code, so before officially releasing it, I wanted to post it in “Beta” form to give everyone a chance to not only test the code but also share their thoughts and suggestions. I’m also thrilled to announce that Grant Skinner (author of gTween) will be collaborating with me on v11 (see separate announcement).

By far the biggest news in terms of functionality is the addition of the “TimelineLite” and “TimelineMax” classes. They make building and managing sequences/groups of tweens simple. They originated from TweenGroup, blossoming into something much more powerful, flexible, and intuitive. Think of the timeline classes much like MovieClip timelines in the Flash IDE where you position individual tweens over the course of time.

More...

Twease Author Backs TweenLite

Posted in Tweening by jack on the April 10th, 2009

Andrew Fitzgerald, the author of Twease, has spent hundreds of hours figuring out how to squeeze maximum features and performance into an incredibly compact tweening package. He began Twease quite a while ago before realizing that TweenLite existed, and needless to say, the two engines share remarkably similar objectives. Andrew announced yesterday that he plans to throw his support behind the GreenSock tweening platform and discontinue development of Twease. It is an honor to have him on board. He has been taking a look at v11 and said he loves the direction. It’s great to know that we’ll have another pair of experienced eyes looking things over, helping to make the platform even more robust and reliable. Welcome to all the Twease users out there.

More...

gTween and TweenLite/Max Unite?

Posted in Tweening by jack on the March 17th, 2009

Grant Skinner is one of the most well-respected Flash developers in the world. His inspiring work and generous contributions to the Flash community have earned him a stellar reputation and countless fans. So it is with great excitement that I announce our collaboration on the upcoming release of TweenLite and TweenMax. Grant’s recent Beta offerings of his gTween engine showed great promise and as we talked, it became obvious that we have similar objectives. We figured it made a lot of sense to put our heads together and build on TweenLite and TweenMax, creating a unified platform that’s better, faster, and more flexible than ever. Grant has a proven track record of looking for ways to benefit the overall Flash community, and this is just one more example. It is truly an honor to have his valuable input.

While we’re confident that the collaboration will bear good fruit, there is always a chance that we’ll hit an impasse. Thus far, however, we seem to share remarkably similar goals, convictions, and…most importantly…initials – “Grant Skinner” and “GreenSock”. Coincidence or fate?

Accompanying this announcement is v11 Beta 1 of the GreenSock Tweening Platform. It’s a work-in-progress, and we welcome your input. Get the details and code here.

More...

Announcing TweenLite/Max Version 10

Posted in Tweening by jack on the January 31st, 2009

This update of TweenLite and TweenMax is probably the most significant ever, so I figured the announcement warranted a page of its own to describe all the exciting enhancements and to answer common questions.Full documentation still resides on the regular TweenLite and TweenMax pages. Version 10 delivers a whole new level of flexibility, performance, and tweenable goodness…

More...

Sneak Peek – What’s Next for the GreenSock Tweening Platform

Posted in Tweening by jack on the December 24th, 2008

I’m working on the biggest update to the GreenSock tweening platform in a long time, and I’m weighing some fundamental decisions about which I’d like your input. I’m also looking for beta testers. Let me outline the enhancements:

  1. Shift to a plugin architecture – Most special properties (like “tint”, “visible”, “frame”, “blurFilter”, “bezierThrough”, etc.) will be separated into optional plugins that can be activated (or not). This makes it possible to only add the features you need and keep file size down and speed maximized. It also means you can author your own plugins to handle whatever special properties you want! If the platform is missing a feature you want, you can probably just write a plugin. And don’t worry – you’ll still be able to tween ANY property of ANY object without plugins. The plugins only apply to properties that require special handling.
  2. Eliminate TweenFilterLite – With the new plugin architecture, you can just activate the filter plugins in TweenLite or TweenMax, so I can’t see any compelling reason to keep TweenFilterLite around.
  3. Add “frameLabel” plugin – Allows you to tween to a particular frame label. It’s just like the current “frame” feature, but instead of defining a frame number, you define the label.
  4. Add “setSize” plugin – Allows for easy tweening of component width/height with setSize().
  5. Add “remove” property to all filter tweens – if “remove” is set to true, the filter will be removed at the end of the tween.
  6. Add “index” property to all filter tweens – allows you to define a specific index number in the DisplayObject’s filters Array where you’d like your filter tween to occur. This is not mandatory – it just provides more flexibility.
  7. Add “addFilter” property to all filter tweens – when addFilter:true is passed in with any filter tween, it forces a new filter to be used instead of trying to use one that’s already there. This is completely optional. Normal behavior is for TweenLite/Max to look for any existing filters of the same kind and tween those.
  8. Add “transformAroundCenter” plugin – scale, rotate, or move a DisplayObject/MovieClip using its center as the origin, regardless of where the actual registration point is. Imagine dynamically loading an image and then scaling it or rotating it as though its registration point is centered. This plugin is a membership benefit of Club GreenSock.
  9. Add “transformAroundPoint” plugin – scale, rotate, or move a DisplayObject/MovieClip using any point as the origin, regardless of where the object’s registration point is. This plugin is a membership benefit of Club GreenSock.
  10. Add “colorTransform” plugin – Accommodates advanced color tweening of a DisplayObject’s ColorTransform like redMultiplier, redOffset, greenMultiplier, etc. It also adds convenient ways to tween the exposure, brightness, and tint amount (so you can tell it to only tint to 50% for example). This plugin essentially replaces ColorTransformProxy – it is more efficient and less code. It is a membership benefit of Club GreenSock.
  11. Change “shortRotation” syntax – Previously, shortRotation could only affect the “rotation” property of an object, but that doesn’t accommodate 3D rotations well (rotationX, rotationY, and rotationZ). So now you can pass an object with any number of properties that should be affected, like: TweenMax.to(mc, 2, {shortRotation:{rotationX:-170, rotationY:100}}).
  12. Speed enhancements (20-50% in some situations!)
  13. Fix some minor overwriting bugs
  14. Eliminate allTo(), allFrom(), sequence(), and multiSequence() from TweenMaxTweenGroup offers the same functionality, plus a whole lot more flexibility and power.

More...

LiquidStage – Automatically Reposition/Stretch DisplayObjects in Full-Browser SWFs

Posted in Transforming, Tweening by jack on the November 8th, 2008

LiquidStage allows you to “pin” DisplayObjects to reference points on the stage or in other DisplayObjects so that when the stage is resized, the DisplayObjects are repositioned and stay exactly the same distance from the reference point(s) they’re registered to. It also allows you to define another pin point horizontally and/or vertically which will change the width/height of the DisplayObject when the stage is resized, stretching it visually. For example, maybe you want a logo Sprite to always maintain a particular distance from the bottom right corner. Or maybe you’d like a bar to snap to the bottom of the screen and stretch horizontally to fill the bottom of the stage. Here is an example of a real-world project that used LiquidStage.

  • Your DisplayObjects do not need to be at the root level – LiquidStage will compensate for nesting even if the DisplayObject’s ancestors are offset (not at the 0,0 position).
  • Repositioning/Resizing values are relative so if you pin an object and then move it, LiquidStage will honor that new position.
  • Not only can you pin things to the TOP_LEFT, TOP_CENTER, TOP_RIGHT, RIGHT_CENTER, BOTTOM_RIGHT, BOTTOM_CENTER, BOTTOM_LEFT, and LEFT_CENTER, but you can create your own custom PinPoints in any DisplayObject.
  • LiquidStage leverages the TweenLite engine to allow for animated transitions. You can define the duration of the transition and the easing equation for each DisplayObject individually.
  • x and y coordinates are always snapped to whole pixel values, so you don’t need to worry about mushy text or distorted images.
  • LiquidStage does NOT force you to align the stage to the upper left corner – it will honor whatever StageAlign you choose.
  • Optionally define a minimum width/height to prevent objects from repositioning when the stage gets too small.
  • LiquidStage only does its work when the stage resizes, so it’s not constantly draining CPU cycles and hurting performance.

More...

Next Page »