I’m sure many people will be curious what the release of GTween v2 means for my relationship with Jack and TweenLite. The short answer is “nothing”. I am continuing to work with Jack to make TweenLite (and the greensock family) better. In fact, I delayed the release of GTween v2 to ensure TweenLite v11 got all the attention it was due.

Given that, you’re probably wondering why I would release a whole new version of GTween. It all comes down to the core nature of each project.

TweenLite is a stable, well supported library with a dedicated developer and a lot of concern for minimizing painful transitions between versions. This commitment to stability makes it a great choice to use as a developer, but it makes it harder to try out radically new approaches or interfaces.

In stark contrast, GTween is an experimental library built entirely to meet my personal needs and whims at any particular moment. It is completely unsupported, and subject to periods of neglect followed by massive rewrites that involve wide ranging changes to its API. This makes it potentially difficult to work with as a developer, but it means I can use it as a sketch pad to try new ideas out, and gain feedback from the brave souls who use it.

As an example, I never intended to write GTween v2. I had planned one more minor release after beta 5 to address outstanding issues, but certainly not a rewrite. However, I was procrastinating on preparing my code optimization session, and started playing with applying some of those ideas to GTween. This sketch rapidly progressed into a whole new version over the course of a weekend. I don’t believe in letting good code rot (I’ve done enough of that in the past), so after consulting with Jack, I decided I may as well polish it up and release it.

I don’t have any current plans to make further updates to GTween. It’s finally a stable, extensible code base that I feel happy having my name attached to. However, you never know what will happen the next time I find myself procrastinating.

So, moving forwards GTween will remain my occasionally updated experiment tweening library. I invite anyone to use it and extend it, but I won’t be supporting it, and I’m not promising any updates. I will be putting more focused energy into working with Jack to improve TweenLite. Jack and I are both hoping that the things I learn from playing with GTween (and the feedback I get on it) will apply directly to making TweenLite an even better library.

On a related note, I know that Jack’s licensing is a bone of contention for some people, but it’s worth noting that this licensing is the reason he can provide support and continue to churn out awesome updates like v11. Open source projects have a habit of dying from neglect when their original author gets busy or bored (see: most libraries I’ve released over the years). Jack has found what I think is a fair compromise, making his library free for almost everyone, but charging for use when it directly makes money. Yes, this complicates things for some projects, but there are alternatives for when you just can’t make it work.

It’s also worth noting that I do not take any share of the licensing fees Jack receives. I don’t get anything out of helping guide or promote TweenLite, except the satisfaction of contributing to one of the best and most popular tween libraries available, and the enjoyment of working with Jack (who’s an all round good guy).

So please, if you play with GTween, give us some feedback. Are there features or approaches you’d like to see in TweenLite? Things you wouldn’t want? Jack and I are both listening.

I’m happy to announce the release of GTween v2. This version is a ground up rewrite of the library focusing on size, speed, extensibility, and improving the readability of the code.

The core library is now just 3.5kb, and it’s 2-5X faster than beta 5 was. GTween now has a simple, but reasonably robust plug-in model, and much of the secondary functionality has been moved out into plugins (ex. snapping, smartRotation, filter support). This has simplified the code a great deal, and made it much easier to understand.

This release comes with a bunch of plugins for common tweening tasks like color adjustments (saturation, hue, etc), synching timeline animations, working with color transforms, run-time calculated motion blurs. It’s also the first release to include a set of easing classes that are optimized for use with GTween.

Finally, this version includes an experimental static interface called GTweener (inspired by Joshua Granick), which provides basic override capabilities.

You can get more information, view demos and documentation, or download the latest version at gskinner.com/libraries/gtween.

What about TweenLite? If you’re curious about what this release means for my relationship with Jack Doyle and the TweenLite library, I invite you to read my blog post on that very topic.

For the sixth year, the gskinner.com crew broke out the brightly colored, child-safe pumpkin tools and mutilated some innocent pumpkins.

As always, we broke into teams of two, based on seniority, ate a lot of sugar, drank a lot of beer, and tried to carve up some cool jack’o’lanterns.

The bar seems to have been raised this year, and I think we have our best set of entries to date. Likewise, I think the voting app is our best yet. According to tradition, it was built by our newest hire. He even built an AIR configuration app for the whole thing. Good work Shawn!

Continue reading →

I think most people can agree that the Flash platform suffers due to the lack of a healthy commercial component ecosystem. We have a fantastic, innovative, and highly prolific OSS culture, and even have a thriving market for small, inexpensive effects and simple components, but we lack the high-quality, well-supported, production-ready components that a commercial marketplace can provide.

This was the (perhaps poorly surfaced) core of my previous post. Adobe has not done a good job of encouraging a commercial marketplace, even often seeming to work against it.

It’s easy to complain, but a whole lot more valuable to actually contribute to a solution. With that in mind I thought it would make sense to solicit feedback on how to improve the environment for commercial libraries and components. I’ll work to consolidate the feedback, and try to funnel it to appropriate people at Adobe.

Of course, this can go beyond Adobe. Is there something that we can change as a community that would help?

So please, leave comments. This is brainstorming so toss in any ideas, comment or elaborate on other people’s ideas, and vote concepts up. Please just keep it focused, mature and respectful. Hopefully

We recently had the pleasure of building the MLB.com OnBase AIR application, which lets you keep track of everything that’s going on with your favourite MLB teams and players via Twitter, official notifications, and game updates. Working with MLB on the project was very cool by itself, but as a cherry on top it is now being advertised in Times Square. It’s pretty sweet to see your work 50 feet tall in Times Square – it’s a little like being a super nerdy and completely unknown broadway star.

I’m very proud of all the awesome work my team did on this one. Consolidating all of the data feeds necessary to power this app in an effective and efficient manner was quite a challenge, and they did a great job of making it happen.

You can get more info on MLB.com OnBase at mlb.com/onbase.

Here’s a picture of the digital billboard in Times Square:

I just filed a feature request for Flash player, asking for a cacheAsBitmapOptions property on display objects. The intent behind this is to make the current cacheAsBitmap functionality more useful. Currently, when you use cacheAsBitmap, the cache is redrawn any time you modify the transform the display object in any way other than translation (moving it in x/y). For example, if you rotate, alpha, or scale your display object it forces the cache to redraw.
It’s often useful to maintain a cache through other transformations, such as rotation, changes to alpha, and scaling. I frequently implement this functionality manually by drawing the display object to a BitmapData, and swapping the Bitmap for the original Sprite. This works, but it’s very clumsy, and requires a lot of manual management.
In conjunction with this, it would be useful to specify the resolution that the bitmap cache is created at, as a scale multiplier of the DO on stage.
The cacheAsBitmapOptions feature I am proposing would let you programmatically specify what transformations would result in a cache redraw. For example:

import flash.display.CacheAsBitmapOptions; // name based on NetStreamPlayOptions
var myOpts:CacheAsBitmapOptions = new CacheAsBitmapOptions();
myOpts.updateOnRotation = false;
myOpts.updateOnAlpha = false;
myOpts.updateOnScale = false;
myOpts.cacheScale = 2;
characterSprite.cacheAsBitmapOptions = myOpts; // passing null would revert to defaults.
otherSprite.cacheAsBitmapOptions = new CacheAsBitmapOptions(2, false, false, false);

If you think this functionality would be useful for your projects, feel free to vote it up. The bug is filed in the Flash Player bugbase as bug #FP-2524.
On Monday I will post a blog entry walking through how to implement this type of functionality manually, with a handy helper class.