Sorta like when using arrows in sprite editor. Because I've came up with a nice waterfall sprite for my secondary project (Contra demake), but it requires me to be able to move it - in theory I could make it so waterfall consists of multiple frames, each slightly moved downwards, but I don't want to waste sprite space like that.
You could put two copies of it in the spritesheet, one above the other, and then just render successive -1 increments to the sy parameter of an sspr() call to move the tile window up (and so effectively cycle the animation down) by one pixel each time. Once you get all the way to the top sprite, jump back down 8 pixels, repeat.
And I am describing a workaround that uses only 2 sprites instead of 8 sprites, and a little bit if runtime code, to do functionally that.
Like joshmillard said, put two of them on top of each other, and then do this:
t += 1 if (t >7) t = 0 sspr (0,8-t,8,8,0,0,8,8)
You get away with 33 tokens, but use 2 sprite slots.
If you really want to use only one sprite, then making two sspr calls, one drawing the top, the other the bottom, and changing this spot could work too, but use a lot more tokens.
This should do the trick if you value one tile of sprite memory over some computational cost:
t += 1 if t > 7 then t = 0 end sspr(sx, sy + 8 - t, 8, 8, dx, dy) sspr(sx, sy, 8, 8 - t, dx, dy + t)
...or this alternatively if you want to run it on a global clock, allowing it to be easily wrapped into it's own function:
--assuming t is defined and iterated somewhere else local clock = t%8 sspr(sx, sy + 8 - clock, 8, 8, dx, dy) sspr(sx, sy, 8, 8 - clock, dx, dy + clock)
Another option is to use the reload() function to overwrite the sprite memory with a shifted copy from the cart memory.
This would use slightly less code than SGET/SSET since you can copy an entire row at once. You could animate multiple sprites at the same time too. Just line them up horizontally in the sprite sheet and shift them all at the same time.
[Please log in to post a comment]