gigbig

I bookmarked this post, maybe I will print and expose it at the office. This is a potential TED that can teach and inspire anyone struggling to start a trip in an unknown land. Thank you Craig!

Well, I have never made externs, wrapped libraries, so I am collecting the necessary infos, will be back as soon as possible to report the list of what I need. If I manage to build a bridge between GSAP and Haxe/Openfl my life will be more complete ?

Hi guys, years ago I did the switch from AS3 to HTML5, and now I am on the Openfl/Haxe ship: it was the most obvious choice for a softwarehouse that wanted a rolling start. It was a pain in the xxx to leave GSAP for basic tweening libs, and after years I still feel this giant hole in the Haxe/Openfl echosystem, a hole that must be fixed, so I am back here to ask you: do you know/use Openfl/Haxe? ----> YES! - ok, someone did externs/wrapper for GSAP modules, but they are dated and incomplete - do you think it would be (a lot) easier to make externs now that there is not the distinction between TweenMax/Lite/Timeline etc anymore? - do you know how to? ----> NO! No problem Thanks

Hi, I am having a really weird problem: my game compiles as always (I didn't change it for months), but today Flash Player (an old version, I didn't updated it) all of a sudden started giving me an error when compiling the recompiled SWF: the error is in the SWFLoader getClass function, it doesn't find a movieclip in the library, but it doesn't simply returns null as always did, it now causes an error that blocks the execution of the debugger! Didn't getClass simply return null if the requested resource was not found?!

No problem Thank you Carl!

I resolved in a different and more mathematical way: xOffset = toX - item.x; yOffset = toY - item.y; var jumpDuration: Number = Math.sqrt(Math.pow(xOffset, 2) + Math.pow(yOffset, 2)) / 500; jumpTimeline = new TimelineLite( { onUpdate: fixY } ); jumpTimeline.to(item, jumpDuration, { x: toX, ease: Linear.easeNone }, 0); jumpTimeline.to(item, jumpDuration / 2, { y: item.y - 200 * jumpDuration, ease: Power1.easeOut }, 0); jumpTimeline.to(item, jumpDuration / 2, { y: item.y, ease: Power1.easeIn }, jumpDuration / 2); private function fixY(): void { item.y += yOffset * jumpTimeline.progress(); } I animate the item as if it was moving on a parabolic trajectory with the same starting and ending Y coordinates, and on each update of the timeline I "fix" the precalculated Y coordinate adding the needed value of the linear Y offset, calculating it by the current timeline progress value. The result is a perfect parabolic trajectory on a fake 3D plane.

Well, I could use yoyo and add a linear offset to y when onUpdate is triggered, I have to try, but before this I have to understand why this doesn't work var jumpTimeline: TimelineMax = new TimelineMax( ); jumpTimeline.to(xxx, 2, { y: 200, repeat: 1, yoyo: true}, 0); I would expect a parabolic trajectory (I removed the X tween part for clarity), to y=200 and back, but yoyo property is ignored, it reaches 200 in 2 secs and stops, why?

Hi, I am trying to create a parabolic trajectory for a movieclip: - I know the starting X and Y - I know the ending X and Y - X movement is linear... - ...that combined with Y must generate a parabolic trajectory simulating the movieclip "jumping" on the 2D plane from Y to Y How can I achieve this effect with GSAP? Thanks

The solution is so obvious that I am blushing: I never considered .set and I wonder why. For what concerns Vars I have to use them more often, as I tend to use always objects. Thank you guys!

I completely rebuilt the method for constructing the timeline, and I found out the problem: everytime a particle was instanced or restored from pooling it was reset to its initial state, and for colorMatrixFilter properties I used a Tween that set the properties asynchronously, so interfering with the effective initial state or the displayed particle. I fixed the problem showing effectively the particle only AFTER this reset process has completed, as it is not instantaneous even if duration of the tween is set to 0.01. Is there a way to remove or set initial colorMatrixFilter state without using a tween? To remove it I can use "remove: true" at completion ok, but to set the initial state? If I use TweenXXXVars, how can I set parameters to emulate the "fromTo" function? If I set parameters using TweenXXXVars I am going to use a "to" function, right.

Sorry, the particle system is instancing cyan dots following the mouse position: I have set brightness to start from -1 to 1, so the darker dots have just been generated: the single bright one (and smallest one) on top of them is the last one generated, with the first frame missing the brightness filter. That was my first try, but behaved the same way. As soon as I can (in a few hours) I will try forcing render: the problem is that it would do this double step at each particle generated.

Ok, I will rework the conditional part. Anyway I have done another test, and as you said the colorize effect is being overwritten by brightness, but the first frame has the same problem as before, look at the attached PNG. New test: I kept colorize only, but the problem persists.

Hi, I am creating a simple particle-system using GSAP, but I am having a weird problem: all the properties used work correctly, except for the ones I add in the timeline with a fromTo tween, color and brightness. Using the following code I obtain a particle that moves, scales, rotates, fades correctly from an initial state, but if I try to tween color and brightness the first frame of the tween has not these two filters applied, just the first one, even if I set immediateRender to true: private function generateTimeline(): void { particleTimeline = new TimelineMax({onStart: onStart, onComplete: onComplete, autoRemoveChildren: true, immediateRender: true}); if (xOut != gfx.x) { xTween = TweenMax.to(gfx, life,{x: xOut, ease: xEase}); particleTimeline.add(xTween, 0);} if (yOut != gfx.y) { yTween = TweenMax.to(gfx, life, {y: yOut, ease: yEase} ); particleTimeline.add(yTween, 0);} if (alphaOut != gfx.alpha) { alphaTween = TweenMax.to(gfx, life, { alpha: alphaOut, ease: alphaEase}); particleTimeline.add(alphaTween, 0);} if (scaleXOut != gfx.scaleX) { scaleXTween = TweenMax.to(gfx, life, {scaleX: scaleXOut, ease: scaleXEase}); particleTimeline.add(scaleXTween, 0);} if (scaleYOut != gfx.scaleY) { scaleYTween = TweenMax.to(gfx, life, {scaleY: scaleYOut, ease: scaleYEase}); particleTimeline.add(scaleYTween,0);} if (rotationOut != gfx.rotation) { rotationTween = TweenMax.to(gfx, life,{rotation: rotationOut, ease: rotationEase}); particleTimeline.add(rotationTween, 0);} if (((colorIn != colorOut) && (colorInAmount > 0 || colorOutAmount > 0)) || ((colorIn == colorOut) && (colorInAmount > 0 || colorOutAmount > 0) && (colorIn != 0xffffff))) { colorTween = TweenMax.fromTo(gfx, life, {colorMatrixFilter: {colorize: colorIn, amount: colorInAmount }}, {colorMatrixFilter: {colorize: colorOut, amount: colorOutAmount, remove: true }}); particleTimeline.add(colorTween, 0);} if ((brightnessOut != brightnessIn) && (brightnessIn != 1)) { brightnessTween = TweenMax.fromTo(gfx, life, {colorMatrixFilter:{brightness: brightnessIn }}, {colorMatrixFilter: {brightness: brightnessOut, remove: true }}); particleTimeline.add(brightnessTween, 0);} } In the attached PNG you can see the blue particle before yellow color is applied. Any suggestion?

Well, I tried to simulate it with your FLA (scaling texts down), but the scrolling was very smooth, I wonder what was the problem in my case. Now I have changed my code a lot so I can't reproduce the old situation, but if Stumble on the glitch again I will tell you for sure. Thank you Carl!

Nice suggestion, I added wrapOffset and obtained the correct scrollX value, thank you! In doing this kind of calculations you need to remember if an item has been scaled, and multiply, where needed, the scale factor as I wrote above. I also noticed that using blitmask to scroll a scaled item implies a minor graphic glitch: to be more precise, this happens for certain values of the scale factor. This would be an argument for a new discussion, but in the meantime I will expose it here. If I have a scaled item like my textLine and I use a blitmask to scroll it I may experience stuttering, but in the wrapped copies only! The "main" instance of the textline will scroll perfectly, while the second, the third etc may stutter depending on the scale factor (certain values are more dangerous than others, like different scrolling speeds may affect this glitch too). If the second instance stutters going back and forth of 1 pixel, the third instance will go back and forth of 1 or 2, and so on, 3, 4, 5 etc, depending on wrapping approximation, I think. This is surprising to me, as I thought that if the blitmask target kept the same scale, its wrapped bitmap version used by the blitmask was not updated at each frame, so intruducing approximation incongruencies between frames, but it looks like I was wrong. Carl, do you confirm my suspects? If this is true, is there a way to update the blitting without redrawing the bitmap?

The perfect formula for the long textline is (textline.width + wrapOffset) / (textline.width - maskWidth) but I wonder why. It does not work with the short textline... Still experimenting... EDIT: the short textline was scaled by 1/2, so I changed the formula like this (textline.width * 0.5 + wrapOffset) / (textline.width * 0.5 - maskWidth) and the result is nearly perfect, apart for a small but visible jump of the textline. Maybe I am going to find the correct formula, but... what am I searching for? Why does blitmask behave like that?

I have tweened the short textline too, and the perfect scrollX value is -0.364: it looks like this value is linked to some sort of calculation of this kind: maskWidth/ (textLine.width + wrapOffset - maskWidth) I noticed that I have a minimum stuttering with scrollX too, but different: it looks like the wrapped texts, the texts repeated at the end of the first textline, move differently from the others, as if they were not part of the same texture, but using blitmask in bitmapMode this shouldn't happen (I think)! Did I overestimate blitmask power or is it still beta? Or maybe it is thought for masks as big as target images only?

I tried to calculate the scrollX value for the wide textline this way: maskWidth / (textLine.width + wrapOffset) the value is about 0.9, as expected, but the scrolling is terribly slow and it scrolls about 150 pixels before repeating it from the beginning. I tried value 20.4, and it is the value I need to obtain a perfect loop for the first line, but I wonder why! The textline length can change, so I need to understand how to calculate the correct scrollX dynamically.

Ok, this is the "to X" approach, what I already did (apart for repeat: -1 ), but what if I wanted to use the "to scrollX" method? TweenMax.to(text1, 10, {scrollX:?, repeat:-1, ease:Linear.easeNone}); and TweenMax.to(text2, 5, {scrollX:?, repeat:-1, ease:Linear.easeNone}); I'd like to try harder with scrollX, because it looks smoother and without stutterings (even if with the described problems): do you think it is possible to use it to loop objects smaller or bigger than the blitmask? Maybe I have to calculate the exact proportion between text and mask width and use it as target scrollX value?

Hi, I am trying to create smooth scroll animations of long text lines, from side to side (like stock exchange running texts). I have tried applying a blitmask to mi text line, activating wrap and tweening the line to a very big negative X: the effect is what I want, but I wonder if this method is slower than using scrollX, as it sometimes stutters on some PCs. I have tried to replace this method using the scrollX property, and the text line scrolling looks a bit smoother, but I have a problem, maybe I didn't understand how to use scroll property the right way. I have two text lines: - the first one is wider than the window, while its blitmask is as wide as the window: I set a small wrapOffsetX to divide the end from the beginning of the wrapped texts, and scrollX = 0 - the second one is narrower than the window, while its blitmask is as wide as the window again: I set a small wrapOffsetX and scrollX = 0 here too How do I write the 2 tweens to scroll the lines from right to left indefinitely? If I set a positive scrollX for the first line it moves from right to left, while the second line moves from left to right! Thanks

Ops, I missed this discussion in the search http://forums.greensock.com/topic/8433-how-to-add-time-at-the-end-of-a-timeline/ sorry. What I need was tl.set({}, {}, "+=4") Done!

Hi, I am trying to create a timeline that contains an ending pause of x seconds: now I can add a delay between tweens, a delay before a specific tween, but... how do I set a delay before onComplete is triggered? I could add a dummy tween at the end of the timeline, with a delay, but it look ugly to me. Am I missing the specific trick? Thanks

Well, yes, I was looking at v11 docs... ok, no problem, I have fixed the problem and I will use the new function to complete/kill the tweens. I read the launch page a few months ago, but it was so full of infos that I missed/forgot the part about killTweensOf, sorry. If only I have had the updated libs from the beginning I would have immediately seen the different name of the second parameter... I am unlucky today Thank you Jack!

I was playing with killTweensOf, and after a few hours of problems I discovered that the documentation is not updated correctly between v11 and v12 (it reports a "complete" parameter that does not exist anymore in v12), that the version I was using was sufering of a bug (the second parameter was an Object intead of a Boolean as declared in the documentation;,updating the libs it has been fixed, but...), and that the second parameter in the new libs version is not "complete" anymore, but "onlyActive"! What a mess! I now wonder if to force tweens completion before killing them I have to use the function you suggested in this thread http://forums.greensock.com/topic/7342-killtweensof-not-working-and-there-is-no-longer-a-complete-param/?hl=completion#entry27578 or if there is a built-in function to automate it. Why did you remove the complete parameter? Thanks

Uh, ok, so it is the right behaviour: I thought that BlitMask was constrained to straight rectangles, and that it couldn't be rotated because of limitations to regular (not rotated) memory areas. Ok, I misunderstood, maybe because I have never seen an example with a rotated BlitMask. This is a very good news because it opens new perspectives for my projects! Thank you Carl and Jack!