Jump to content
GreenSock

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

gigbig

Members
  • Posts

    59
  • Joined

  • Last visited

gigbig's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. 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?!
  2. 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.
  3. 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?
  4. 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
  5. 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!
  6. 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.
  7. 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.
  8. 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.
  9. 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?
  10. 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!
  11. 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?
  12. 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?
  13. 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?
  14. 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.
×