Question

I need to do an endless horizontal scroll of elements within a parent MovieClip.

No matter what ever method I try, an element of ‘drift’ occurs and eventually the elements start to overlap.

I’ve tried using relative recursive tweening for each element according
but this method seems prone to quite a bit of error after repeated starts and stops.

//CODE START
      function doScroll():void {
         TweenLite.to(this, .25, {x:"20", ease:Linear.easeNone,onUpdate:checkPos,onComplete:doScroll});
     }
//CODE END

I’ve reverted to doing absolute tweens to a predefined position using a contant speed. This seems to be more accurate but still some ‘drift’ occurs.

//CODE START
//_dest is predefined 
var speed:Number = 500;
var dist:Number = this.x - _dest;
var distAbs:Number = dist < 0 ? -dist : dist;
//kludge to get constant velocity by recalculating time every frame
_time = distAbs / speed;
TweenLite.to(this, _time, {x:_dest, ease:Linear.easeNone,onComplete:reset});
//CODE END

Thought this should be very simple.
Can anyone point me to any possible tutorials or make any suggestions?

Any help appreciated.

Answer 1

Solution/Discussion at http://forums.greensock.com/viewtopic.php?f=1&t=6800

(warning: this is gonna require a rather lengthy explanation…)

It’s a logic problem in your code. In your onUpdate, you were running conditional logic such that if the x position is beyond 980, it kills the tween and moves x back to -980 and starts things over. You’re doing that for each individual item, each of which begins at a different position. That initial position affects when it crosses that threshold, thus when they reposition, the offsets are different.

For example, let’s say item1 starts at an x position of 0 and item2 starts at 490 and both start moving at 400 pixels per second and your frame rate is 60, thus they’ll move 6.66666 pixels per frame. Item1 will take 147 frames to hit 980. However, item2 will take 74 frames (actually 73.5, but there’s no such thing as a half-frame) to cross the 980 threshold, but when it does so it will be at an x position of 983.333333. At that point it jumps back to -980 due to your conditional logic, but notice that it traveled an EXTRA 3.333333 pixels. You intended Item1 and item2 to travel at the exact same velocities and they do during the tween, but your onUpdate logic is misaligning them on the reposition such that in the end, some are traveling more than others which affects their overall velocity.

Another issue has to do with the fact that Flash rounds x/y coordinates of DisplayObjects to the nearest 0.05. So when you do your manual reposition (wrap), small rounding errors creep in. For example, let’s say TweenLite sets the exact x value to 980.799. Flash will actually round that to 980.75. Then when you reposition it like this.x -= 980 and then tween it, the value would have just lost almost 0.05 pixels on that round. Do that many times and it can add up to a half-pixel or whole pixel (or more). All your items are crossing the threshold at slightly different spots, thus the rounding errors aren’t the same, thus you start seeing slight variances in the spacing. Again, this is NOT an issue with the tweening engine. You’ll see that the engine itself sets the values correctly, but Flash rounds them internally when applied to DisplayObjects.

A solution was posted at http://forums.greensock.com/viewtopic.php?f=1&t=6800 that includes an FLA and support files.

As others have suggested, I’d recommend having a single chunk of code that manages ALL the items that you’re aligning/scrolling. It would lay things out from a single reference point so that everything lines up perfectly every time. You could tween a getter/setter that applies the logic. I use that technique all the time and it works great. You can see a smaller-scale example in the code I attached in the above URL (the scrollX getter/setter in ItemBase.as)