Jump to content

Search In
  • More options...
Find results that contain...
Find results in...

GreenSock last won the day on July 24 2019

GreenSock had the most liked content!


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by GreenSock

  1. Did you still have a question? Did my answer address your concern? Again, you should be able to disable TransformManager stuff by setting the enabled property to false.
  2. You should be able to simply set the "enabled" property to false on the TransformManager instance (or any individual TransformItem). Is that what you were looking for?
  3. Actually, that's not entirely true. The speed difference can be very important even with one or two tweens. Imagine two buttons next to each other with Tween-based rollovers. If the user rolls back and forth between them, speed is very important to ensure there's no perceivable lag time in the rollovers/rollouts. I had the exact same thought for quite some time actually. But people kept asking for more advanced features, especially filter and bezier tweening. I brushed 'em off for a while, but eventually they wore me down and I created TweenMax Now it seems to be getting quite popular. I really want to minimize the trade offs developers face when "upgrading" to TweenMax. File size probably doesn't matter that much, but if the speed drops off significantly, it becomes very unattractive. It's a balancing act. I'm not opposed to using GoASAP. I certainly see some benefits, but I also see trade offs which may not be acceptable to the user base. That's why I started this poll in the first place - to see what the consensus was. It seems like speed is extremely important to folks and outweighs the convenience factor of building on top of GoASAP (so far). It may sound easy to just crank out another "GoTweenMax" class, but I've learned the hard way that it's a lot of work to maintain and support. Every time I add a feature to one, I'd need to add it to the other and work within two different frameworks. I'd also need to adjust things as Moses (and others) update the core GoASAP framework which takes even more time and increases the chances of bugs. I'd much prefer to pick a route and go with it as opposed to maintaining and supporting two TweenMax variants. I appreciate all the input guys. I'll keep the poll open for a while more, so encourage your friends to vote.
  4. If you prefer not to use the built-in delete functionality, you can manually do it by removing the DisplayObject (removeChild()) and then call the removeItem() method on the TransformManager for that particular item that you deleted.
  5. It's easy to disable TransformManager from handling DELETE/BACKSPACE stuff - just set the allowDelete property to false. Then you can handle all that stuff manually. I'm not sure you can disable the DELETE key inside TextFields - I've never tried that. Seems like it'd be really frustrating for users though. You sure you want to do that?
  6. Sure, you can add hew MovieClips dynamically. Just don't forget to add them to the TransformManager instance, not just the stage. Also, be SURE you wait until the new MovieClip has FULLY loaded and instantiated, otherwise TransformManager will not be able to measure it correctly. Maybe even wait a few milliseconds after the onLoadInit is called from your MovieClipLoader just to be sure. Use the addItem() to add it to TransformManager.
  7. Every time you call TweenMax.to() or TweenMax.from(), you're actually creating an object. You can keep track of it like this: var myTween:TweenMax = TweenMax.to(my_mc, 2, {x:"300"}); And it starts automatically, but you can always pause() it and resume() later. Or for even more control, use the progress property. For example, to make it skip to half-way through, you can set myTween.progress = 0.5. And if you want to set up a sequence, look into the sequence() and multiSequence() methods. Lots of options
  8. Glad to hear it's workin' for you. As far as deleting TextFields, that's a tricky situation because the user must be able to use their BACKSPACE/DELETE key to interact with the text, so how would you know, for example, if when they hit the DELETE key that they wanted to delete the entire TextField as opposed to just a character inside the TextField? In my opinion, you'd need to create a separate button that the user would click to remove the TextField altogether.
  9. So it's workin' for you now, right? (once you disabled keyboard shortcuts)
  10. Are you just testing it in the authoring environment? Or are you testing it in a browser? Keep in mind that if you want to test that kind of stuff in the authoring environment (test movie), you need to disable keyboard shortcuts. People make that mistake all the time. If you don't do that, Flash intercepts the special keys (like DELETE).
  11. I'm not quite clear on what the problem is. The Array you pass in to the constructor is just for the initial setup - TransformManager doesn't keep track of that Array and see if/when you add anything to it. Think of it as a convenient way to get around having to do a bunch of addItem() calls if you've already got a bunch of items on the stage that you want it to manage. Of course you could use addItems() too which is another convenience. If you're going to add items to the TransformManager after it's instantiated, you need to use the addItem() or addItems() methods. Is that a problem?
  12. Sure. I assume you're talking about the upcoming AS3 version of TransformManager, right? You can dynamically create Sprites and/or MovieClips and add them anytime. Either like this: var manager:TransformManager = new TransformManager({targetObjects:[square1, square2,text]}); or like this: var myTargets:Array = []; //create Sprite here and draw a rectangle with the drawing API, then... myTargets.push(myNewSprite); myTargets.push(myNewMovieClip); var manager:TransformManager = new TransformManager({targetObjects:myTargets}); or like this: var manager:TransformManager = new TransformManager(); manager.addItem(myCustomSprite); manager.addItem(myCustomMovieClip); or even var manager:TransformManager = new TransformManager(); manager.addItems([myCustomSprite, myCustomMovieClip]); Lots of options to choose from And you can remove them anytime with the removeItem() function too. Does that answer your question?
  13. Actually, that has nothing to do with TransformManager - it's just that Flash cannot rotate TextFields that use device fonts. You're using device fonts, right? (like _sans or _serif, etc.) As you can see in the demo, TextField with embedded fonts can rotate without a problem.
  14. That's actually one of the key features in the new AS3 version that I'll be releasing shortly. It was a lot of work to get it working just right. I had to rebuild the entire class from the ground up. You can see an interactive demo of the AS3 version at http://www.greensock.com/ActionScript/T ... nager/AS3/. But sadly, the AS2 version does not have that capability. It would be possible (though time consuming) to port the improved AS3 version back to AS2 as long as you could target Flash Player 8 (because it uses Matrices). If you'd like to hire me to do so, contact me off the forums. But if there's any way you can target AS3 in your project, I'd highly recommend it.
  15. I'd suggest looking at the Flash Help docs on the Graphics.lineStyle() method. I think it's the 5th parameter that you'd want to set to LineScaleMode.NONE if you don't want it to scale.
  16. Sure. Look at the documentation for the sequence() and multiSequence() functions. Example: TweenMax.multiSequence([ {target:mc1, time:1, x:300, y:100}, {target:mc2, time:2.5, scaleX:2, autoAlpha:0} ]); Documentation is at www.TweenMax.com
  17. Keep in mind that all scaling occurs from the registration point. You drew your rectangle so that its x/y position is 10, 600. So when it's at a scaleY of 1, your rectangle starts 600 pixels down from the registration point of its parent. Then, when you tween to scaleY of 3, the rectangle will look like it starts out at a y-coordinate of 1800 (600 * 3). You might want to change it so that the graphics rectangle x/y coordinates are zero, but move the entire Sprite's coordinates down 600 pixels. That way, when you scale it, it'll look like the upper left corner is pinned to where it started. Hope that helps.
  18. Moses Gunesch has created a very fast, lightweight core AS3 animation framework that he's proposing as a standard of sorts. You can learn more about it at http://www.goasap.org. He's done a great job of making it fast, but due to several factors I won't go in to right now, TweenMax would be slower if it was built on the GoASAP framework. It definitely wouldn't be a good fit for TweenLite because it would more than double the file size. In fact, here are some benchmarks I ran: GoASAP-based size: 6600 bytes TweenLite size: 3096 bytes GoASAP-based speed (without overlap checking): 45.5fps GoASAP-based speed (with overlap checking): 3.9fps TweenLite speed (with overlap checking): 51.7fps As you can see, the speed was somewhat close when I turned off the overlap monitor but since by default, TweenLite overwrites competing tweens of the same Object, it seems necessary to turn that on. It’s not an apples-to-apples comparison with the overwriting, though, because TweenLite takes an "all or nothing" approach (overwriting all pre-existing tweens of the same Object OR not overwriting any if you set overwrite:false) whereas I believe the GoASAP framework checks each individual property for overlaps. Also, Moses has been kind enough to take on the job of optimizing the code for use with his engine (and tweaking his engine to make it work better with TweenMax), so the speed gap will likely get even smaller, especially the overlap checking - my version may have implemented it incorrectly or something because those numbers seem way out of whack. In the end, the GoASAP version may only be 1 or 2 fps slower when pushing around 1500 instances which is pretty darn good. Since TweenMax isn't so concerned about file size, it would be the only engine of mine that I'd consider building on GoASAP. So if the GoASAP-based version is slower and fatter, why would I even consider it? Well, as Moses explains, it can be very convenient to have a single core engine that's driving everything in your SWF. For example, if you had a physics engine and a 3D engine and a tweening engine running on a common framework and you wanted to pause everything, you could do it in one place instead of 3. Plus it could be convenient to have all the systems synchronized so that when an UPDATE event is dispatched, you know that the physics, 3D, and tweening values have all been updated. I'd like to serve you well, so please let me know what you think - should I rework TweenMax so that it's built on top of the GoASAP framework? Are the speed and file size trade offs worth the increased flexibility and convenience?
  19. I received an e-mail today asking for clarification on 7 different features in TweenMax, so I figured I'd post the answers here in case it's helpful to others... This is a little tricky to understand at first. Keep in mind that I built this feature to be flexible enough to accommodate a lot of different uses including 3D Bezier paths. Basically, in order to figure out a rotational value, it needs 4 pieces of information: coordinate A, coordinate B, the rotational property to affect, and an angle offset. Let's take a simple example in 2D space to begin with: In this example, each point has an "x" coordinate and a "y" coordinate which are used to determine the angle between them. That angle needs to affect a particular property of your tweening object. In a typical situation with a tweening MovieClip/Sprite/DisplayObject, that property will be named "rotation" (or "_rotation" in AS2). But what if you want your MovieClip oriented so that its top was always pointing into the direction of the Bezier instead of its side? That's what the angle offset is for. TweenMax always adds this value to the rotation, so in our case, we'd want it to add "90" (90 degrees). To feed those pieces of information into TweenMax's orientToBezier special property, it would look like this: AS3: [["x", "y", "rotation", 90]] AS2: [["_x", "_y", "_rotation", 90]] Keep in mind that if you're going to use the standard values with no angle offset, you can simply pass in a Boolean value of true and TweenMax will set up the Array for you. But what if you're tweening in 3D and you have 3 different rotational properties to affect ("localRotationX", "localRotationY", and "localRotationZ")? No problem. That's why the orientToBezier special property accepts an Array of Arrays, so you can do any number of rotational properties. For example, you might do: orientToBezier:[["x", "y", "localRotationZ", 0], ["z", "x", "localRotationY", 0], ["z", "y", "localRotationX", 0]] NOTE: As of 6/25/08, Papervision 3D appears to apply the rotationX, rotationY, and rotationZ properties according to the world coordinates instead of the object's local coordinates which prevents this 3D implementation of orientToBezier from functioning properly. Again, this feature was built so that it could accommodate many different scenarios and custom property names, etc. You're not locked into only using "x", "y", and "rotation". Let's say you have a "CustomButton" class that creates buttons with a fill color and an outline color (get/set with fillColor and outlineColor properties). How will you tween those colors? It's simple with TweenMax's hexColors special property. Here's a quick example: var myButton:CustomButton = new CustomButton(); TweenMax.to(myButton, 2, {hexColors:{fillColor:0xFF0000, outlineColor:0x00FF00}, ease:Strong.easeOut}); Basically, you wrap all your hex color properties into one "hexColors" Object and TweenMax takes care of the rest. Let's say you set up a bunch of tweens that are sequenced one after the other and you want a particular function to run as soon as the 3rd tween begins. That's what onStart is for, and onStartParams just gives you a way to pass parameters to the onStart function. Let's say you're tweening values in a MovieClip's transform.matrix. Flash requires you to re-apply that matrix in order to see the changes. So you could do something like this: var myMatrix:Matrix = myClip.transform.matrix; TweenMax.to(myMatrix, 2, {a:2.5, b:0.5, onUpdate:applyMatrix, onUpdateParams:[myClip, myMatrix]}); function applyMatrix($clip:DisplayObject, $matrix:Matrix):void { $clip.transform.matrix = $matrix; } Basically, onUpdate runs every time the values are updated inside the tween (on every frame). The "matrix" property just gives you a way to pass in a particular matrix to tween to (or from). For example, let's say you play with the saturation, brightness, and other sliders in the Flash IDE and want to match that EXACT effect using TweenMax. Maybe you have a button that applies different filter settings, but you want a way to get back to that original effect that you created in the Flash IDE. You can do it by looping through the filters, finding the ColorMatrixFilter on your clip, and grabbing its matrix property and then pass that into TweenMax anytime you want to get back to the original values. The "relative" property can come in handy when you want to apply an effect relative to where it's at now. For example, let's say your clip already has a ColorMatrixFilter effect that's making it very saturated and you want to make it darker by tweening to a brightness value of 0.5. If you just tween to brightness:0.5, it will lose the saturation effect that you had applied. But if you set relative:true, the effects kinda stack on top of each other. If you're asking how to tween a bunch of clips to a common set of values, that's precisely what the TweenGroup.allTo() and TweenGroup.allFrom() methods are for (which got moved to TweenMax.allTo() and TweenMax.allFrom() in v11). To accomplish your example, you could do: v10: TweenGroup.allTo([myClip1, myClip2, myClip3, myClip4], 2, {x:100}, TweenLite); v11: TweenMax.allTo([myClip1, myClip2, myClip3, myClip4], 2, {x:100}); There is also a VERY handy feature named "stagger" that allows you to stagger the effect easily. If you set stagger to 0.1, that would cause myClip1 to start it's 2-second tween first, then 0.1 seconds after that, myClip2 would begin, then 0.1 seconds after that, myClip3 would start, etc. I really like using the TweenGroup.allFrom() (or TweenMax.allFrom() in v11) with stagger to have stuff fly into place on the screen during intros. I sure hope that clears things up for you (and others). Let me know if you need any more clarification. Jack
  20. When I first created TweenLite, I was facing a challenge of making it easy for designers and newbie developers to use, so I chose to use the "gs" package name instead of "com.greensock". It seemed better because: 1) It made the class more usable without import statements (which confused some people). They could simply call gs.TweenLite.to()... which was more compact and intuitive than com.greensock.TweenLite.to() 2) Designers and newbie developers were confused by the nested folders required to use a package like "com.greensock". I've received a few requests to switch the package from "gs" to "com.greensock" because it'd be more "standardized". I've hesitated thus far because I'm afraid it could really confused a large portion of the user base who have already built projects with the old package and then if they upgrade, it'd break their applications. Granted, a search and replace should fix it, but newbies might struggle with it. Also, there are a lot of forum posts, tutorials, etc. on the web that reference "gs.TweenLite" which would suddenly not work. So what do you think? Is it worth all that potential headache for users to switch to "com.greensock"? Or should I stay consistent and continue using "gs"? Frankly, I'm leaning towards keeping "gs" unless a huge majority of you vote for switching. Let me know what you think.