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?