You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
I have a single-row looping reel. I have set spacing:2 which means that even though the reel area is 100px wide, for each frame the background image gets shifted horizontally by 102px. Makes sense, no issues with that.
However, at some point in the code, opt.rows gets set to 1, even though I specified rows:0 in the reel setup call.
Because rows now equals 1, when the backgroundPosition is calculated, it triggers the logic that handles multi-row situations (but only when spinning 'backwards').
This causes the background image to be shifted up one row. Normally this wouldn't be noticed because it's a repeating background, however because I've set spacing=2, it means that the background shifts up 2 pixels whenever spinning in one direction, but not the other!
...which in the case of a horizontal scroller defines the vertical background position offset.
The implication of the above is that if rows=1, and you're scrolling not-backwards, then the vertical offset factor should be 1 time the height of the image. Spacing gets added to this, hence my original problem. If you're scrolling backwards, then the vertical offset is zero. (OR, if rows was maintained at the value of 0, the vertical offset would be zero, hence my prior fix above)
Here's a fix which works for my specific situation:
I'm trying to come up with a test evidence, but so far it all fits. Let me explain what is happening in the above calculation, because as it seems, you only miss 2 pixels of empty space below your sprite.
It has to do with a not much used directional ability of Reel object movies. One such is the Reel logo itself on the homepage - the arrow changes direction to always point "forward". This is achieved by two sprites sheets in one sprite file. One sprite above the other, one for clockwise and one for counter-clockwise motion.
This example of directional sprite is configured as footage: 6, frames: 36, but as you can see, it actually has 72 frames.
The line above does the switching from one to the another by shifting the view by a full number of sprite rows (be aware, these rows refer to the "lines" in sprite, not multi-row rows - unfortunate naming mishap..). Intention is that for regular non-directional sprites the repeated nature of CSS backgrounds won't disclose the shift at all.
So, be sure to add the not just in-between individual frames, columns and lines, but add the spacing below the sprite too. That should help.
What's true on the other hand is that this directional mode should only be engaged when directional option is true, so I guess this really makes this a bug! ;)
Issue should be fixed now (with no need to adjust the sprite like I've suggested earlier). Please give it a try. As always, patched code is in the development branch. Thanks!
The situation is this:
spacing:2
which means that even though the reel area is 100px wide, for each frame the background image gets shifted horizontally by 102px. Makes sense, no issues with that.opt.rows
gets set to 1, even though I specifiedrows:0
in the reel setup call.spacing=2
, it means that the background shifts up 2 pixels whenever spinning in one direction, but not the other!The calculation in question is (line 1358):
...which in the case of a horizontal scroller defines the vertical background position offset.
The implication of the above is that if
rows=1
, and you're scrolling not-backwards, then the vertical offset factor should be 1 time the height of the image. Spacing gets added to this, hence my original problem. If you're scrolling backwards, then the vertical offset is zero. (OR, if rows was maintained at the value of 0, the vertical offset would be zero, hence my prior fix above)Here's a fix which works for my specific situation:
But I don't really understand the reasons for the calculations in that line, so the above might screw up other situations...
The text was updated successfully, but these errors were encountered: