A.D.A. Amiga Demoscene Archive

@Kalms

Perhaps you could do the first 4x64 pixels using 4 pairs of 64-bit sprites, and the last 4x16 pixels using 4 pairs of fake-16-bit sprites though?

(i.e. what happens if you write SPRxDAT manually when sprites are in 64bit mode? will the remaining 48 bits be cleared, duplicates or left as-is?)

I had the same idea while writing my previous post. I don't remember now
what happens to SPRxDAT. I think you cannot write to SPRxCTR, otherwise you stop the DMA. This prevents from writing the least significant bit of the sprite hor. position. No big deal.
It could be worth trying!

who's going to be brave enough to give it a go? :) (im too khikhen)

Hi,

Yesterday I checked sprite manual mode ( sprite dma off ) on my machine ( A1200 Blizzard 1230 IV with 32 mb ).
Results for sprite 0. Important part of copperlist from test program.



1) 32-bit sprite ( SPR32 is set in FMODE - bit 2 ) then SPRxDAT is duplicated. Mean if SPRxDAT contains $ffff then on screen you will see. $ffff,$ffff ( for $f0ff ---> $f0ff,$f0ff )

2) 32-bit sprite ( SPAGEM is set in FMODE - bit 3 ) then first 16 pixels are crashed ( blinking some random shit ), next 16 pixels from SPRxDAT.
3) 64-bit sprite ( SPR32 and SPAGEM is set in FMODE - bit2 and bit3 ) then first 16 pixels are crashed as above and next 48 pixels are duplicated from SPRxDAT. Mean SPRxDAT = $ffff, then on screen $xxxx,$ffff,$ffff,$ffff ( $xxxx = random blinking data )

Any comments are welcome.

Regards

This does not surprise me. I think that at some time around year 2000 I had tried to use manual sprites wider than 16 pixels and failed. I don't remember.

God, how much time has passed since my last post here... :-(