AGA: Using 32 pixel sprites twice per scanline

[buzzybee]

Hi guys!

I´m currently developing a new game for AGA called RESHOOT. One obstacle I´m currently facing is: How could I possibly re-use a 32 pixel sprite twice in one scanline, each carrying different bitplane data in SPRrxDATA?

I was successful with repositioning the sprite several times on one scanline, but can´t copy new 32 pixel data into SPRrxDATA for each re-used sprite, neither using copper nor the cpu. Anyone ever solved this?

[Toni Wilen]

AFAIK it is not possible. CPU and copper <> custom register accesses are still 16-bit in AGA.

[hooverphonique]

yes, since there's only 8 SPRxDAT's, I guess having sprites wider than 16 pixels is not possible without DMA...

[Mrs Beanbag]

i did try hammering the SPRxDATs with the CPU (longword writes), it did seem to affect the full 32-pixel width but not in any useful way, it is a shame they didn't design this feature in because it would have been really useful. i don't suppose turning sprite DMA off and on again mid-line does anything?

At least with 64-pixel wide sprites, you can cover the entire screen with only 5 of them, and then there's that bit you can set that makes all sprites appear twice on a scanline (with the same data)

[buzzybee]

I´m aware of that "one sprite twice per scanline"-bit, and maybe I´ll use it for displaying a 16-color-background some other day. For RESHOOT though it´s kind of useless ...

Thanks for all your answers. So it seems I´ll have to choose another solution for displaying several score items within the playfield ...

[TheDarkCoder]

Mrs Beanbag: which bit??! I remember one that repeats the same data on two consecutive scanlines, so it doubles the sprite height. But not the one you say

Please enlighten me! :-)

[Toni Wilen]

http://eab.abime.net/showpost.php?p=401996&postcount=15

[buzzybee]

That bit repeats every sprite at x-position + 256, with the same pixel content. Therefore can be used for 16 color scrolling backgrounds with 4 attached 64-pixel sprites (64+64+64+64=256, then repeat) provided that background consists of repeating patterns. Not of use for RESHOOT, but valuable nonetheless.

[ReadOnlyCat]

Originally Posted by Mrs Beanbag

i did try hammering the SPRxDATs with the CPU (longword writes), it did seem to affect the full 32-pixel width but not in any useful way, it is a shame they didn't design this feature in because it would have been really useful. i don't suppose turning sprite DMA off and on again mid-line does anything?

At least with 64-pixel wide sprites, you can cover the entire screen with only 5 of them, and then there's that bit you can set that makes all sprites appear twice on a scanline (with the same data)

I guess the test which remains to be done is writing to

SPRxDAT

with the copper and see if this works any better. At least timing is more controllable this way in case this matters.

[buzzybee]

I tried writing to SPRxDAT with both, CPU and Copper. No controllable results whatsoever.

[buzzybee]

Okay, it´s reliably working now. By using the copper, I reuse sprite7 twice on some scanlines. The sprite is initialised by DMA, then (on some scanlines) the copperlist takes over for sprite reuse. As I can rewrite the first word of SPRxDAT only, I´m reusing sprite7 only at the very right border and only the leftmost 16 pixels of it. The border covers all remaining pixelgarbage. SPRxDAT is written by the copper, which is filled by cpu elsewhere in the code. For my game RESHOOT I use sprite7 to display simple messages concerning highscore achievements.

This is how part of the copperlist looks like:

copGame
cwait $2001
cmove $1fc,%0000000000001011 ;32 pixel sprites

cwait $ffdf ; wait needed for correct re-init of coplist
cwait spriteScoreYPosition<<8+spriteHiXPosition+8 ; drawing symbols to hSprite7
cmove $178,spriteHiXPosition+$10
copSprite7PixelData
cmove $17e,0 ; filled by cpu elsewhere in the code
cmove $178,spriteHiXPosition
cwait (spriteScoreYPosition+1)<<8+spriteHiXPosition+8
cmove $178,spriteHiXPosition+$10
copSprite7PixelDataOffset=*-copSprite7PixelData
cmove $17e,0
cmove $178,spriteHiXPosition
cwait (spriteScoreYPosition+2)<<8+spriteHiXPosition+8
cmove $178,spriteHiXPosition+$10
cmove $17e,0
cmove $178,spriteHiXPosition
cwait (spriteScoreYPosition+3)<<8+spriteHiXPosition+8
cmove $178,spriteHiXPosition+$10
cmove $17e,0
cmove $178,spriteHiXPosition
cwait (spriteScoreYPosition+4)<<8+spriteHiXPosition+8
cmove $178,spriteHiXPosition+$10
cmove $17e,0
cmove $178,spriteHiXPosition

; cmove $09c,$8010 ; init copper interrupt -> yet not needed
cwait $3801 ; wait for end of frame, then restart coplist
dc.w $80
copGameH
dc.w 0,$82
copGameL
dc.w 0,$88,0
cend

[hooverphonique]

neat.. is there any particular reason for waiting for end of display and then explicitly triggering coplist0?

[buzzybee]

Yes. I´m using the same copperlist-main-initialisation for all views in the game (title, game...). This keeps the code organised and also helps to keep one visual style in all parts of the game. At the end of copperlist-main-initialisation, copper is pointed to dedicated sub-copperlists which serve dedicated needs of the different displays. At its end each dedicated sub-copperlists is pointed back to the copperlist-main-initialisation. Registers $80 and $82 are loaded with the addresses by the cpu, register $88 (or COPJMP1) inits the jumps.

The titlescreen for example uses 64-pixel-sprites, the game-display 32-pixel-sprites and could do display changes every scanline, as it does by reusing sprite7. Therefore what I´ve copied from my code is only part of the sub-copperlist for the ingame-display.

[Mrs Beanbag]

that's a cunning trick...

by the way, when i was testing i noticed a slightly different behaviour when hammering the SPRxDAT, between the two different types of 32-pixel wide sprites. For the benefit of the spectators, you can get 32-pixel wide sprites either by doubling the bus width or by doubling the data fetch, to get 64 pixel wide sprites you do both of these things. So there are two ways to get 32 pixel wide sprites. I don't know how exactly this makes a difference but anecdotally, it seemed to, although neither mode appeared very useful.

I wonder what happens if you prod the SPRxDAT in the middle of a sprite being displayed?

[ReadOnlyCat]

Originally Posted by Mrs Beanbag

I wonder what happens if you prod the SPRxDAT in the middle of a sprite being displayed?

I suspect Denise caches the content of each sprite into its own registers instead of relying on Agnus to store them: it would be too costly and slow if it had to read them from Agnus using the internal bus every time the horizontal comparator matched.

This means that these registers probably are not at risk of suffering of the "must wait one DMA cycle after access from the chips" problem so upon writing the

SPRxDAT

registers, they are probably transferred immediately into Denise and used immediately for display.

I am obviously just guessing but I am fairly sure Toni must have more grounded ideas about it.

[Toni Wilen]

Yeah, Denise has two sets of sprite data registers, one that stores Agnus DMA/CPU writes (SPRxDATA, SPRxDATB) and output shift registers where SPRxDATA/SPRxDATB gets copied when sprite's X coordinate matches Denise's internal horizontal counter.

Bitplanes use very similar setup but have 3rd set (DMA storage, copy to temp storage when BPL1DAT is written, copy to output shift registers when BPLCON1 matches)

All CPU/Copper accesses to custom registers are always 16-bit. Technically there could have been some logic in Budgie that detects 32-bit CPU's 32-bit write and allows it to be full 32-bit also from Denise point of view (instead of telling the CPU that bus is 16-bit, you need to do 2x16-bit accesses to address+0 and address+2)

Remember that in hardware level single long read or write to address X is not necessarily same as 2xword write/read to addresses X+0 and X+2.

I think the main reason was compatibility and cost. Practically every software that hits the hardware does long writes to DMA pointer registers. I assume there is also programs that do long writes to DAT registers to clear them quickly and would break if single long write does not hit 2 16-bit DAT registers instead of single in 32-bit mode. Handling this fully would have required extra (possible a lot more), internal logic to bus controller (Budgie in A1200).

[ovale]

If I load in a 32 pixel sprite ABCD via DMA and then I write EF via Copper what I will see 256 pixel later? EFCD, ABEF, EFRR, RRCD (R=random) ?
And what will happen with 64 pixel sprites?

[Toni Wilen]

Originally Posted by ovale

If I load in a 32 pixel sprite ABCD via DMA and then I write EF via Copper what I will see 256 pixel later? EFCD, ABEF, EFRR, RRCD (R=random) ?
And what will happen with 64 pixel sprites?

I don't know, I haven't tested.

I'd assume first 16 pixels are replaced but this is most likely undefined situation (I don't think hardware designers cared about "manual" sprite mode in 32/64 wide fetch modes) and there may be some unknown hardware side-effects that can cause odd behavior.

[Mrs Beanbag]

hm, maybe time for some more tests then...

are the output shift registers internally 64 bit? Can you "catch it with its pants down" and write 32/64 bit data by writing to SPRxDAT sequentially at the right time?