Sprite multiplexing on Amiga

[DanScott]

well, disabling sprite DMA while a sprite is being displayed, gives the horrid vertically repeating sprites, but if you are moving the horizontal position into a non-displayable area, i guess it should work

[Lazycow]

ok, let's hope the best. Another thing: Will it speed up the CPU when I disable sprite-DMA? I know that 5 or 6 plane bitmap DMA will slow down the CPU, but sprites?

[phx]

Originally Posted by Lazycow

Instead I used the copper and just disabled sprite-DMA with
dc.l $00960020
...and moved the sprites into the horizontal blank.

When you disable DMA, then no more new data is fetched into SPRxDAT. But the sprite is still armed and writes its last data every line, as DanScott already mentioned.

Usually you have a similar situation when you take over the system and disable all DMA. Sloppy coders forget to disarm the mouse pointer sprite, which sometimes shows as a long vertical bar over the screen. In this case you either have to write zeros to SPRxDATA/SPRxDATB or disarm the sprite with writing 0 to SPRxCTL.

Originally Posted by Lazycow

ok, let's hope the best. Another thing: Will it speed up the CPU when I disable sprite-DMA? I know that 5 or 6 plane bitmap DMA will slow down the CPU, but sprites?

No, I don't think so. Sprite, Disk and Audio DMA slots are fixed. Nobody else can use them (ok, except the last sprite DMA slots may be overridden by bitplane DMA).

[Toni Wilen]

Originally Posted by phx

No, I don't think so. Sprite, Disk and Audio DMA slots are fixed. Nobody else can use them (ok, except the last sprite DMA slots may be overridden by bitplane DMA).

They have fixed positions but if DMA channel is not needed for current line (even if DMA channel is enabled), it's slot(s) can be used by other lower priority channels, including CPU.

[phx]

Wow! I wasn't sure about that. Nice!

[DanScott]

Originally Posted by DanScott

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

I can now confirm, everything works as was anticipated

[dalton]

Is it possible to update the pos/ctl/pth/ptl registers using the copper or cpu, and then have sprite dma immideately fetch pixel data at pth/ptl? Or will dma always start by fetching the two control words at pth/ptl (effectively discarding what the copper or cpu wrote)?

[Toni Wilen]

Originally Posted by dalton

Is it possible to update the pos/ctl/pth/ptl registers using the copper or cpu, and then have sprite dma immideately fetch pixel data at pth/ptl?

Yes. Sprite hardware does not care what is the source of write access. But note that first line that allows sprite DMA (25 if PAL, 20 if NTSC) will always do normal DMA accesses (if sprite DMA is enabled) which can cause unexpected surprises. It is best to do manual writes after line 25/20.

For example Superfrog and Project-X uses this method.

[Photon]

Turning off sprite DMA when it or bitplane DMA is on is the common reason for rolling sprites. The recommended method is to change sprite DMA only during vertical blank (as in: before the magic scanline, see Toni's comment).

It's untested whether setting 0 bitplanes with dc.w $0100,$0200 is a suitable replacement. Any write to BPLCON0 enables bitplane DMA and so should enable sprite DMA IIRC and not work. Maybe Toni could verify.

Hmm, I hesitate moving this and the other sprite thread in General to Asm/Hardware, because there's already one there... Maybe I should, anyway?

[mcgeezer]

Apologies for resurrecting an old thread but it may be useful for others.

I'm trying to multi-plex two sprites on the Y Axis and wondering what is the easiest best way to achieve what I want.

Here is a video of the task/problem at hand:

[ Show youtube player ]

The cars are all 64 width hardware sprites, when they explode I simply change the sprite pointers to the sprite data that I have in memory. What should happen in the game is that when the helicopter sprite passes over it should place the car at the Y position where the player respawns to. In the video the helicopter flies to the bottom of the screen and then it is able to place the car because the hw sprite is no longer used.

The HRM says that I can link two hardware sprites together by placing their data structures straight after one another, the problem with this is that I would have to blit the two sprites together which would give a performance hit. As the video shows I'm loading the sprite data with the copper, if I wait for a specific line in the display I could do it that way, but then if multiple cars crash it would screw up.

Is it even possible for example to set the sprite structure pointers at line $25 for Sprites 0 & 1 (the car) which in their control words have a line position of 70, then after that sprite has been displayed re-arm the sprites with a different data structure showing the helicopter?

Am I over thinking this or will I have to copy the two sprites together?

In Rygar I had set screen positions in the copper to reload the sprite data, this isn't the same because the cars can crash at any y position.

Got me scrahting my head this one - and I think i'm making hard work of it.

Cheers,
Graeme

[Samurai_Crow]

How many colors are your sprites using individually? By setting the even and odd sprite banks to different palette offsets you can give each AGA sprite a separate 3 colors independent of one another. That way you can keep your sprites on 2 bitplanes.

[mcgeezer]

Originally Posted by Samurai_Crow

How many colors are your sprites using individually? By setting the even and odd sprite banks to different palette offsets you can give each AGA sprite a separate 3 colors independent of one another. That way you can keep your sprites on 2 bitplanes.

Sprites are attached and 16 colours. No getting away from that i’m afraid.

Re-reading the thread i’m thinking about using a copper interrupt every 8 lines down the screen, if the chopper is beyond the respawn point for the car then it will set the new sprite addresses and rearm with update to sprpos.

I’ll try it today.

[LeCaravage]

Originally Posted by mcgeezer

Is it even possible for example to set the sprite structure pointers at line $25 for Sprites 0 & 1 (the car) which in their control words have a line position of 70, then after that sprite has been displayed re-arm the sprites with a different data structure showing the helicopter?

To be honest I'm not sure to understand all because I'm tired and my english is kinda weak but if my memory serves you could use copper to rearm sprites ctrl pointers and x,y but using $140,$142 etc and you don't need to wait end of previous sprite.
If I'm off track please forgive me

Edit : So you don't need to copy datas with blitter or cpu

Edit bis : Of course, $142 needs to point directly to sprite date and not sprite ctrl.

[mcgeezer]

Another related problem I have is hardware sprite clipping, is there an easy way to do it on the Y Axis?

My spites are 116 pixels tall for the car explosion, if the car explodes at the top of the screen I can't clip just the lower part of the hardware sprite.

I do have a solution but it isn't elegant, is there another easier way to do it?

[DanScott]

Originally Posted by mcgeezer

I do have a solution but it isn't elegant, is there another easier way to do it?

Depends on what you non-elegant method is..

I would write the control word into the sprite data at the correct place (having saved that off somewhere)... then next frame, restore the sprite data that the control word overwrote, and write the next frames control word in wherever needed.

[mcgeezer]

Originally Posted by DanScott

Depends on what you non-elegant method is..

I would write the control word into the sprite data at the correct place (having saved that off somewhere)... then next frame, restore the sprite data that the control word overwrote, and write the next frames control word in wherever needed.

Non-elegant method....

The original explosion sprites were in an IFF with a resolution of 320x580 taking up 93kb, this gave me 25 64x116 sized sprites - most of which were empty. So due to the clipping problem I ran into, I halved the sprite sheet size into 64x58 and got rid of the blank sprites as a result. The only problem was I had to duplicate some sprites, but it still resulted in a chip memory saving of around 10kb.

I might revisit it and see if I can manipulate the control words, but my original multiplexing problem still stands which I need to figure out.

See attachments for the explosion graphics and what I did with them.

[jotd]

about sprite clipping, is there a way to clip sprites horizontally ?

left of screen: can the amiga use a control word with negative X so the right part of the sprite is drawn?

right of screen: my game area doesn't end exactly at the end of display (status bar on the right). ATM the way that works is to put a sprite of higher priority on the side with a black forground

but then I have palette issues and I need a super complex copperlist to dynamically change palette.

There's also dual playfield, but using DPF just for that brings other problems.

I think I'm going to create another sprite area and shift it manually. Any genius ideas?

[ross]

Originally Posted by jotd

ATM the way that works is to put a sprite of higher priority on the side with a black forground

EDIT:
Ok, main idea is 'abuse' ATT bit for 16 bit sprites, see next message.

I did not understand the problem on the left, which in fact does not exist, just put an x lower than the one that makes the sprite appear at full

[roondar]

Originally Posted by jotd

left of screen: can the amiga use a control word with negative X so the right part of the sprite is drawn?

Amiga Sprite X coordinates start at raster position 0, or about 128 pixels before the actual start of a standard display (which is at position $80/128). Because of this, you can move a sprite partly off-screen to the left without any problems.

right of screen: my game area doesn't end exactly at the end of display (status bar on the right). ATM the way that works is to put a sprite of higher priority on the side with a black forground

but then I have palette issues and I need a super complex copperlist to dynamically change palette.

Another option is to colour the right status bar background (and all other status bar elements) in a different colour than colour 0 and dynamically set the Sprite priorities to be behind the playfield using the Copper for the status bar area (switching back after).

[jotd]

Originally Posted by roondar

Amiga Sprite X coordinates start at raster position 0, or about 128 pixels before the actual start of a standard display (which is at position $80/128). Because of this, you can move a sprite partly off-screen to the left without any problems.


Another option is to colour the right status bar background (and all other status bar elements) in a different colour than colour 0 and dynamically set the Sprite priorities to be behind the playfield using the Copper for the status bar area (switching back after).

both are very good points. The sprite xy table I have doesn't take "negative" coords into account. I have to fix that.

And the playfield priority trick pleases me because I don't have to change palette dynamically, which is a nightmare for me.

But then I don't have enough colors to use another black color. Game uses 16 colors, and I don't want to go full 5 bitplanes just for this. But it would be very quick as it would not change a lot of stuff. In that case I could reuse one of the black colors of the sprite palette.

Damn, that problem is not that easy. but thanks.

On the other hand, not sure shifting the sprite data at each frame would be costly either on a 16x16 sprite, only for 1 or 2 sprites max.