"Codetapper to the rescue" - about the Risky Woods sprite trick

[Tigerskunk]

Hello guys (and especially Codetapper, if you read this... ),

What I get from the Risky Woods sprite trick is, that there are 8 sets of 4*16 sprites to switch to one after another after the background was scrolled 2 pixels.

What I don't get is: the whole block is 64 pixels wide, why is it enough then to only scroll 16 pixels? Wouldn't you need either 32 sets of these 4*16 blocks or at least 4 different copper lists to switch to one after another to get this trick going?

Is this missing from the description on Codetappers site, or am I missing something here?

Why are only 16 steps needed?

Btw, Noticed the same thing on the R-Type 2 pages description about this trick...

[ross]

If I had to make a similar effect I would actually use only 8 copies.
At the beginning of the screen I would load the pointers to define start y, stop y, x low bit and attach with standard DMA.

During the display I will multiplexing on the x on fixed position (since there would not be enough DMA slots to change SPRxDATx, but SPRxPOS).
Then i'll shift the low bit x on sprite list every pixel and the new sprite image every two with copper.
Then after 16 pixels i'll "rol" sprite 0->1-> and so on, so actually position of sprite 0 is the same but with sprite 1 data and so on.

[EDIT: well, of course if attach bit is set you need to rol 0&1->2&3->.., but you've got the point ]

[EDIT2: I looked for my old sources, but I have an incredible mess and not found yet
(In the early '90s?) I had written code to use dual playfield, plus animated "almost full screen" sprites multiplex, to create triple smooth parallax effect.
Well, it seems to me it did not cover the whole screen (too much DMA required..) and there were not so many useful cycles to do who knows what, but a great proof of concept.
I also remember to have used the attach bit trick to make a "partial coverage", 16 colors in the center and 4 colors on the sides so as to have two sprites to cover 24 pixels with "16 colors" (ex: 8p+8p+8p->4c+16c+4c).]

[Tigerskunk]

Originally Posted by ross

Then after 16 pixels i'll "rol" sprite 0->1-> and so on, so actually position of sprite 0 is the same but with sprite 1 data and so on.

Aaaaah! Heureka!

That's the missing piece...!

Thanks, Ross...