Sprite multiplexing on Amiga
 

Hi,

Is sprite multiplexing on Amiga more suitable to make backgrounds composed of sprites with repeated patterns (changing POS,DATA,DATB registers with the Copper) or can it be really used to efficiently display lot of moving objects (on x and y axis) ?

I'm used to sprite multiplexers on C64,
I don't find Amiga sprite structures very easy to handle lot of objects.
If doing a multiplexer with a single hardware sprite:
The objects graphics must already reside in the sprite structure and be y ordered.
If the objects are animated, new images of the objects have to be "blitted" into the sprite. I don't see a real advantage then to use hardware sprites compared to bobs for moving objects ... Unless I missed something.

bobs have to be blitted using all 3 source channels (slowest way to blit)
bobs need to be "cleared", or have the screen data put back before re-plotting at a new position (slow)
bobs also need to be shifted if they are to move smoothly in the X axis (adding an extra 2 bytes to the width of the blit)

Even if you have to blit some data into the sprite (to animtate it for example), it is only an A->D quick copy blit.. and of course you could use the copper or blitter interrupts, so that the blitter is doing these things "in the background", while the CPU is getting on with other things.

You are right mixing control and data wasn't a smart choice.
Anyway, you can use the copper to change registers on the fly as you do with the c64.

yes you can do either a manual sprite with the copper or semi-automatic sprite multiplexers, where you have separate "sprite structures", each one to display a single sprite.

Yes, effectively sprites are far less time consuming regarding blitter operations involved compared to bobs.

But how to make an efficient "semi-automatic" multiplexer on one or several hardware sprites ?

- Order the objects according to their y pos.
- dispatch the ordered objects into several sprite structures (if into SpriteN a previous object has not finished to be rendered for the Y start pos of the current object, skip to the SpriteN+1..etc.). Compute the sprite words control.
- blit the images of the objects into the sprites structure.
- Do that each frame

And voila ?

yes, something like that :)

and if the sprite list is already in y sorted order... then once all sprites have been moved to their new positions... up a bit, left a bit.. down a bit. right a bit.... you can be pretty sure that the list is still in a reasonabley "nearly sorted" order... and can be re-sorted really quickly, without needing to run a full sort algorithm on it :)

The other thing you can do, is if it is not possible at all to find a free slot for a sprite (because of too many on the same Y band), then you could flag that sprite for that frame, not include it... but on the next frame include that one and not include another one.. this will cause them to flicker at 50hz.. which is better than totally not showing it :)

If you have a hw sprite with the full stop 0 data, will it re-start if you use the copper to write to the sprite registers again after the full sprite has been displayed?
I.e. can you re-arm the DMA sequencer?

I did some quick tests, and seems that you can't arm the DMA later on down the screen. don't know what the limit is, but imagine it is before bitplane fetching has started.

Toni Willlen will know for sure,,,

I am loading my SpritePtr's at line $10, giving me enough time in the vertical blank interupt to update everything that needs updating :)

I am not sure if I have ever confirmed this.. I'd assume Agnus only loads internal vertical sprite DMA enable/disable comparators when Agnus does sprite control word DMA fetch. (and it gets ignored if Copper or CPU does it)

Non-DMA sprite mode should be always possible. (even when DMA is active)

So, what does happen when you reset a sprite pointer midway through the screen?

The Codetapper sprite tricks site suggests that Stardust used this + setting new sprite pos/ctl values during the tunnel sequences to multiplex sprite images. But if I understand what Toni wrote this shouldn't work unless the sprite was never 'ended' in the first place.

You change the sprite pointers during the display to chain together different sprites structures in memory. Sprite DMA occurs at the beginning of the scanline, so wait until the last line of the sprite and hpos 20 or something, and change the pointer to a new pair of control words and sprite data.

The problem is of course that pairs of sprites share the same palette, but this way you can atleast avoid the overhead of copying sprite data around in memory.

I remembered wrong, it is possible to modify sprite SPRxPOS any time to restart sprite in DMA mode that has already "ended". Of course new sprite vertical position needs to be same or larger than current vertical position.

Hardwired sprite DMA enable line is 25 (PAL) or 20 (NTSC), line when first control words are always loaded. (if sprite DMA is enabled)

Yes, this is what I meant to say with "semi-automatic" mode

Hello

Is there some available sources that show those beautifull coding tricks ?

Alain Thellier

You should't really need sources... it's just about writing to the SpritePtrs, and using the copper at particular lines to re-arm the DMA or write sprite data into the SprData & SprPos registers.

Just a few minutes "tinkering" you can get something working that follows some of what was written above :)

hmm.. one crappy demo I did in past had sprite playfield and other stuff done using repeating sprites: http://kestra.exotica.org.uk/files/s...5000/7322c.png

Loads of copperlist stuff to poke sprite registers.

The sinus scroller is on a 1 color "sprite playfied" on a top of a 16 color picture, the animated 4 color knobs are also sprites and far at the right side is (not shown now) is another 16 color sprite to hide the overscan scroll register caused whatever crap there always was by displaying part of the logo in that sprite :) I have no idea what I did back then anymore, though.. but can try to look for sources..

To make it clear (for me), let's make an example:
Sprite 0 is displayed at VPOS 100 with a single line. At VPOS 101 Agnus reads SPR0POS=0 and SPR0CTL=0, which means the sprite display list has ended for this frame.
Now I want to display a second sprite display list on channel 0 starting at VPOS 200. My copper list waits until a line between 101 and 200 to set the SPR0PT to the new display list. Then it writes SPR0POS and SPR0CTL to re-arm the DMA channel. Is that correct?

If what Toni says is correct, then yes, that should work.

I need to do something similar myself, probably this week sometime, as I just don't want to be building huge sprite DMA lists, when I can easily use the copper to write new pointers, and re-arm the DMA with a quick couple of copper moves (ie. for large animated sprites that will be "plexed" vertically).

I will post the results of my experimentation here ;)

Interesting sprite bonus infos! Just one thing: I did not end my sprites with $00000000, because my sprites are bigger than the screen and sometimes I am a lazy cow.
Instead I used the copper and just disabled sprite-DMA with
dc.l $00960020
...and moved the sprites into the horizontal blank. It seems to work, but should I expect strange side effects?