Posted on January 28, 2009 by Grant SkinnerAnother new feature I’ve added to GTween beta 5 is support for synchronizing timeline animations with scripted tweens. This lets you ensure that animations will remain synched even if you change the framerate of your FLA or if you pause, reverse, repeat, or otherwise manipulate your tweens. Here’s a simple demo of it in action. The run cycle and fire are frame by frame animations, all other animation is done with GTween. Notice how the run cycle always lines up exactly the same with the motion tweens (despite everything being time based) and how it pauses along with the rest of the animation. The fire is not synchronized, so it will continue to play when the tween pauses, and is affected by framerate. Also worth noting: the fire’s visibility is controlled through another new feature of beta 5, which improves on progress points. Best part, its only a few lines of fairly readable code for this whole demo.
AC_FL_RunContent( 'codebase', 'http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=10,0,0,0', 'width', '550', 'height', '400', 'src', '/blog/assets/GTweenRunDemo', 'quality', 'high', 'pluginspage', 'http://www.adobe.com/go/getflashplayer', 'align', 'middle', 'play', 'true', 'loop', 'true', 'scale', 'showall', 'wmode', 'window', 'devicefont', 'false', 'id', 'GTweenRunDemo', 'bgcolor', '#000000', 'name', 'GTweenRunDemo', 'menu', 'true', 'allowFullScreen', 'true', 'allowScriptAccess','sameDomain', 'movie', '/blog/assets/GTweenRunDemo', 'salign', '' ); //end AC code Still working on crushing bugs, cleaning up documentation, polishing samples, and finalizing the feature set for beta 5, but I hope to release it early next week. UPDATE: UPDATE 2: Fixed. Not a player bug. It was an issue with iterating a Dictionary, and the order was different in debug and regular players. Actually helped me improve on the reliability of the sequencing engine.
Follow @gskinner on Twitter for more news and views on interactive media.
|
|
|
14 Comments
I'm seeing the running start on the same level as the box here.
Windows XP Professional, Google Chrome ( though is the same on firefox 3 and ie 7 ), Player 10,0,12,36
Posted by: aA on Jan 28, 2009 10:37pm URL: http://moads.wordpress.com
I see the bug too - runner starts at the height of the box - OS X 10.4.11 Safari 3.2.1 player 9.0.151.0
Posted by: Lex on Jan 28, 2009 10:46pm
seeing the same thing:
Firefox 3.0.5
Windows Vista Home Premium 64bit
Flash Player 10,0,12,36
not happening in same system with IE 7.0.6001.18000 32 bit with player 10,0,2,54
no flash in 64 bit version of IE
Posted by: mauricio giraldo on Jan 28, 2009 10:52pm URL: http://www.mauriciogiraldo.com/blog
Google Chrome, win xp, player version 10,0,12,36
I can see the bug.
Wish you luck on fixing the bugs.
Hope you'll release GTween soon. Looks like complete solution for the most programmatic animation scenarios.
Posted by: Nikita on Jan 29, 2009 12:20am URL: http://nikitadudnik.com/blog
The first time he runs to that box it's ok. All other times he will start running too high.
Opera 9.63
Player 10,0,12,36 Release
Posted by: Erik on Jan 29, 2009 12:41am
Same thing happens to me. It starts off just fine, but when it starts to loop, the runner is box-high.
Ubuntu 8.10, both Firefox 3.0.5 and Opera 9.51, with Player 10,0,15,3 installed
Posted by: Alex on Jan 29, 2009 1:06am
Runs perfect here:
Flash Debug 10,0,0,525
FF 3.0
Windows XP
Posted by: ockley on Jan 29, 2009 1:10am URL: http://www.hjaelpmignu.dk
same here with Firefox 3.0.5, OSX 10.5.6, FP 10,0,12,36
FP 10,0,12,36 debug is working fine.
Posted by: Martin on Jan 29, 2009 1:11am URL: http://www.formatlos.de
The box bug doesn't appear on my winbox with Vista in FireFox 3.0.5 with fp10,0,12,36 (debug)
but it does appear in IE 7.0.6001 with fp9,0,124,0(normal)
And I get another bug approximately 7 out of 10 times: if I click the animation to pause it, after the runner has passed the fire and then restart it, then the anim automatically pauses when the runner is at the edge of the screen. This happens in both players.
Posted by: creynders on Jan 29, 2009 1:22am
Updated to player 10.0.12.36. First, normal player (made the bug) and then debug player (worked alright).
... Hmm, guess that's why they called it the "debugger" ;-)
Happy hunting, Grant.
/ockley
Posted by: ockley on Jan 29, 2009 1:24am URL: http://www.hjaelpmignu.dk
FP 10,0,12,36 Mac (regular version) on WebKit => the runner starts at box height when it loops. Probably something related to the old asynchronous issue when calling gotoAndStop (which I think was solved on FP10).
Posted by: Gabriel Laet on Jan 29, 2009 5:40am URL: http://gabriellaet.com
creynders - that was actually expected behaviour. It was set to loop 3 times and then stop at the end. I've uploaded a new demo that loops continuously so that it's a bit less confusing.
Posted by: Grant Skinner on Jan 29, 2009 9:38am URL: http://gskinner.com/blog/
Great! Can't wait till i can get my hands on the new beta :)
Posted by: DataGreed on Jan 29, 2009 1:42pm URL: http://blog.datagreed.ru
@grant: ok, makes sense, but was confusing.
Just tested it here at home on win XP in FF3.0.5 with fp9,0,124,0 (normal) and IE6.0.2900 with fp9,0,124,0 (normal) and both work great.
Posted by: creynders on Jan 30, 2009 2:58am