Multiple sprite copies

[REAKTOR BEAR]

At the moment we are using copperlist to initiate sprites during vblank, but that only gives us 8 sprites on the same display-line spr0, spr1, spr2, spr3, spr4, spr5... and so on.

Is it possible to have multiple copies of a sprite on the same display line?

[paraj]

Yes, but you have to usual manual mode for the repeated sprites. On Codetappers site there are a number of examples that might inspire you: https://codetapper.com/amiga/sprite-tricks/

But since that technique is limit you may want to rethink (or describe) what you're trying to do.

[REAKTOR BEAR]

We are trying to display a 96px wide attached sprite with 16colors on A500 OCS. So that will require using some sprites multiple times on the same display line. 12 sprites are needed for 96px, 16colors.

Seems like this guy is using that kind of method, recycling 2x sprites to fill the entire background.
https://codetapper.com/amiga/sprite-tricks/jim-power/

[jotd]

I'm pretty sure that you cannot change the sprite data itself, just repeat the same sprite pattern with this technique.

does this trick work with attached sprites? another interrogation.

I've successfully implemented sprite multiplexing (with ross' help), but defining a "high" and "low" zone.

Typically, it is possible to use 8 sprites per playfield for an horizontally split screen 2 player game (like Lotus)

[Coagulus]

There was this? [ Show youtube player ]

[mc6809e]

Originally Posted by jotd

I'm pretty sure that you cannot change the sprite data itself, just repeat the same sprite pattern with this technique.

does this trick work with attached sprites? another interrogation.

I've successfully implemented sprite multiplexing (with ross' help), but defining a "high" and "low" zone.

Typically, it is possible to use 8 sprites per playfield for an horizontally split screen 2 player game (like Lotus)

Data can be changed, too. In fact a write to sprxdata is necessary to rearm the sprite if the sprite was disarmed at some point with a write to sprxctl.

[REAKTOR BEAR]

Thanks for all the great info, we ended up using copperlist and flipping the bitplanes settings on different vertical positions of the screen. And thanks to paraj for that awesome link to Sprite tricks.

[ross]

Originally Posted by jotd

does this trick work with attached sprites?

It works, but the problem increases because two sprites must have the timed setting for the repositioning of the x position (and possibly a change in shape data).
You have to find some compromises regarding the number of bitplanes or copper effects you want to be able to do on the same video line.
This type of multiplex is really heavy, so even the use of blitter is limited because there are few free DMA slots left in the frame

[mc6809e]

Originally Posted by ross

It works, but the problem increases because two sprites must have the timed setting for the repositioning of the x position (and possibly a change in shape data).
You have to find some compromises regarding the number of bitplanes or copper effects you want to be able to do on the same video line.
This type of multiplex is really heavy, so even the use of blitter is limited because there are few free DMA slots left in the frame

The recent thread by !ZAJC! https://eab.abime.net/showthread.php?t=117203 suggests that in theory MOVEM.L to sprite registers with race-the-beam style/cycle exact programming is possible and would maximize unique sprites per line. Blitter would have to be off/paused of course. Lots of limits.

Not sure anyone has ever tried it on the Amiga though I think Jay Minor who also designed the atari 2600 would have certainly approved.

[ross]

Originally Posted by mc6809e

The recent thread by !ZAJC! https://eab.abime.net/showthread.php?t=117203 suggests that in theory MOVEM.L to sprite registers with race-the-beam style/cycle exact programming is possible and would maximize unique sprites per line. Blitter would have to be off/paused of course. Lots of limits.

Not sure anyone has ever tried it on the Amiga though I think Jay Minor who also designed the atari 2600 would have certainly approved.

I see major limitations in using movem.l for sprites.
In any case, one is forced to use writing blocks that include from SPRxCTL to SPRxDATA (in reverse mode), so it would only be useful for complete updates of both the position and the shape (all 'repetitions' or partial positionings or partial data would be excluded).
Furthermore, synchronization with the CPU would take away many precious cycles, however you intend to do it (a problem that you wouldn't have with Copper).
It is probably a technique that has never been used because it does not have great advantages
Obviously it could work and as a proof of concept it would be feasible (a massive sprite background!).
But there are other more interesting things to try

EDIT: And I forgot another fundamental point!
Copper is memoryless.
Instead, even after having filled all the possible registers of the sprites with the CPU, you need to re-fill the CPU registers for the new re-writing, which you must necessarily fetch from memory, and you must do it 'racing the beam'.
At that point you lose all the advantages you had gained using the technique...

[mc6809e]

Originally Posted by ross

I see major limitations in using movem.l for sprites. <snip>
At that point you lose all the advantages you had gained using the technique...

You make good points.

One thing, though. As long as movem.l uses some addressing mode other than predecrement mode memory is written to in-oder. This works for updating a sprite completely since a write to sprxclt disarms a sprite while a write to sprxdata realms it and they are they're mapped to memory in that order.

But, yeah, trying to cram all that data into registers between scalines would be tough.

Maybe a hybrid approach could work. Let DMA take care of four/six sprites and cpu the other two/four. Memory accesses would interleave.

Meh. Probably still too many issues.

[ross]

Originally Posted by mc6809e

One thing, though. As long as movem.l uses some addressing mode other than predecrement mode memory is written to in-oder. This works for updating a sprite completely since a write to sprxclt disarms a sprite while a write to sprxdata realms it and they are they're mapped to memory in that order.

Right
Also it is better since there is no variation of the base register in the case of rx-ry,(ax)
I misremembered the order of the registers..

[REAKTOR BEAR]

On A500 OCS, lowres, 1bitplane, single playfield, Auto-loaded sprites... Sprite6 is somewhat defective, and Sprite7 is missing in action. Is there some setting in BPLCON to fix this issue?

sprcopper:
	dc	spr0pth,$0000
	dc	spr0ptl,$0000
	dc	spr1pth,$0000
	dc	spr1ptl,$0000
	dc	spr2pth,$0000
	dc	spr2ptl,$0000
	dc	spr3pth,$0000
	dc	spr3ptl,$0000
	dc	spr4pth,$0000
	dc	spr4ptl,$0000
	dc	spr5pth,$0000
	dc	spr5ptl,$0000
	dc	spr6pth,$0000
	dc	spr6ptl,$0000
	dc	spr7pth,$0000
	dc	spr7ptl,$0000

spr0pth = $120
spr0ptl = $122
spr1pth = $124
spr1ptl = $126
spr2pth = $128
spr2ptl = $12a
spr3pth = $12c
spr3ptl = $12e
spr4pth = $130
spr4ptl = $132
spr5pth = $134
spr5ptl = $136
spr6pth = $138
spr6ptl = $13a
spr7pth = $13c
spr7ptl = $13e

[a/b]

Do you use overscan, how your dma fetch window looks like ($dff092/94)?
http://amigadev.elowar.com/read/ADCD.../node02D4.html

[DanScott]

With DDFSTART set for scrolling (ie 16 pixels to left of regular display window), you lose the last sprite and half of the previous sprite, as bitplane DMA steals those slots