I've been attempting to setup horizontal loop scrolling with a linear stack of small imagesprites. On screen init. the sprites don't line up to where they are suppose to? Can someone please help me see what I'm missing?
Instead of using black vertical image buffers to cover the swapping within the screenview I've added the width of the scrolling image sprite to the left and to the right of the canvas. The mechanics would ideally be that a line of 4 or 5 (could be more) chained blocks continually scrolls through the screen and the image sprites swap from the left unseen side to the right unseen side. I'm trying this idea instead of making a huge canvas (x2-x4 size) to attempt for better performance.
I added 3 ball sprites colored in sequence like a traffic light as canvas landmarks (see attach). Red ball marks the unseen start of the canvas, yellow ball marks the start of the screen and the green ball marks (supposed to) the end of the screen and the start of the unseen canvas area on the right side. The 3 green ball sprite does not go to the desired place on screen init either.
I've been encountering a glitch, it seems that every third sprite or higher I try to setup init coordinates for does not go to its desired spot on screen init. Third ball sprite or image sprites 3 and 4 don't go to their spots, but manually right clicking and choosing "Do it" command on their block logic puts them right where they are supposed to be.
For ease of testing:
- I have setup the scroll clock to turn on or off on canvas tap.
- I've setup the screen alignment to switch through its 3 settings on canvas swipe so its easy to see where the image sprites are at any given point
PS. still need to work on eliminating the gaps between the image sprites when they swap. Tips would be appreciated but it's not a priority, more worried about the right setup on initiation first :)
Thanks for the help and the amazing community this program enjoys
--
I see! Thank you so much. So screen init does not effectively resize the canvas and must be set individually with a clock in it's own step. I will be applying the principle and thank you.
Also thank you for the comment explaining the purpose and use of the math block "floor". In spite of the definitions provided by app inventors help section I have a difficult time understanding this block and other blocks like modulo that I see used around for animation or placement purposes.
I think I finally see why sometimes using a sine fx to increase and reduce the size of a sprite (different practice exercise) was acting buggy on me. Without the floor block I was getting decimals of pixels of target sprite size which must have not been registering like you suggest the canvas needs.
I'm assuming it's safe to say in layman terms that the floor block rounds down to the closest whole number
--
Also thank you for the comment explaining the purpose and use of the math block "floor". In spite of the definitions provided by app inventors help section I have a difficult time understanding this block and other blocks like modulo that I see used around for animation or placement purposes.
I think I finally see why sometimes using a sine fx to increase and reduce the size of a sprite (different practice exercise) was acting buggy on me. Without the floor block I was getting decimals of pixels of target sprite size which must have not been registering like you suggest the canvas needs.
I'm assuming it's safe to say in layman terms that the floor block rounds down to the closest whole number
--
I'm assuming it's safe to say in layman terms that the floor block rounds down to the closest whole number
floor really just truncates a number at the decimal point:
floor(4.9) -> 4
Of interest also is MITAI's method of rounding.
It uses round-to-even which means that if a decimal is exactly N.5 then if N is odd it rounds down, if even it rounds up!
round(4.5) -> 5
round(7.5) -> 7
Why?
Because that method when used with a large set of values gives a better average result than always rounding down.
But it is a bit confusing.
--
Understood! Thank you for taking the time to explain it. I appreciate every bit of knowledge on math and coding principles to improve my animation skills :)
--
댓글 없음:
댓글 쓰기