A.D.A. Amiga Demoscene Archive

Hi folks,

since I'm fiddeling about on the AGA chipset again, I ran into some colliding issues while trying to display 64 pixel attached sprites on a quite normal AGA bitplane screen.

1)

The screen is set up in with an AGA palette, 8 bitplanes ( 64 bytes wide), Fetch Mode ( $1fc ) = 0 and has a bunch of standard Blitter shifting going on.
In addition to that scene I wanted to include said 64 pixel sprite in 4 bitplanes depth (i.e. 16 colours).
I looked at the example that is provided with PicCon and saw that in order to display such attached sprites the global scan-doubling bit is to be lit in FMODE, which consequently messes up all other activity on the screen.

Now, is there a way to circumvent the global scan-doubling by telling the sprite control registers ( SPRxPOS / SPRxCTL ) to "scan-double" individually ?

...and since I've already mentioned my dear friend the Blitter...

2)
I'm moving a number of BObs over the screen and use the following LF-combination: D = A+C ( $FA ).
A = BOb
C = D

But it leads to "glitches" when BObs are overlapping each other. Rule for the scene is: I'm blitting back to front,
so each new BOb overwrites the current background. Pretty much "cookie cut" style.
The glitching of course comes due to the "OR" with the current "background" ( C ) where bits in the bitplanes that are dark in the BOb ( A ) are lit on the background ( C ).
Is there a better LF combination for that without adding "B" to the equation ?

Don't remember about #1, but for #2:
if your bob is more than one color then you need to use A,B, and C. I recommend using A as the bob mask and b as the bob graphics. The reason is that when blitting bobs you need to add an extra word for scrolling, and by using A for the mask, you can set modulo to fffe and the A last word mask to 0000, and you don't need to waste 2 bytes per line.

also remember to set the scroll registers for both A and B to draw it properly

As for 1):

FMODE settings for sprites shouldn't affect settings for bitplanes and vice versa. Also, scandoubling is independent of data fetch for both sprites and bitplanes. Thus:

Bits 0 and 1: bitplane fetch
Bits 2 and 3: sprite fetch
Bit 14: Bitplane scandoubling
Bit 15: Sprite scandoubling

You should always use 64-bit bitplane fetch (bits 0 and 1 both set to 1), as this will minimize bitplane DMA load on chip memory. You just need to adjust the display data fetch registers ($dff092 and $dff094) to appropriate values. The correct values for non-overscanned (320 pixels wide) bitplanes is $dff092 = $38 and and $dff094 = $b0. Also, your bitplane data must be 8-byte aligned.

To use 64-pixel wide sprites, set bits 2 and 3 to 1. The sprite control words then must be placed 8 bytes apart instead of the usual 2 (i.e. 6 bytes of unused space after each of the words), followed by 16 bytes of data for each sprite line. Again 8-byte aligned.

There it is. The 8-byte alignment did the trick.
Also I think I've lost my head while writing the question about the scan-doubling bit in the FMODE.
I confused FMODE set to $f ( bits 0 - 3 ) with $8000 ( bit 15 ).
The only thing else that was necessary to do was to adjust the modulos a bit.

BTW, I think you must've meant the Data Fetch Stop to be $d0 instead of $b0, right ?

Thanks people. Another small victory in the up-hill battle until Easter :)

No, I did mean $b0. For 16-bit fetch, $d0 is the correct value. If you set it to $d0 with 64-bit fetch, the bitplane DMA will read 8 bytes too much on every scanline. You can compensate for this by setting the modulos to -8, but this results in 8 bytes of useless DMA traffic per scanline. Setting Data Fetch Stop to $b0 and the modulos to 0 gives the same result with less DMA traffic.

Hmm. My current screenbuffer - Modulo setting is as follows:

screenbuffers: 64byte wide * 256 lines * n bitplanes
display: 40 bytes wide * 180 lines * n planes ( adjusted to position well on the monitor with DIWSTART/STOP)

64 bytes because Y position calculating is reduced to lsl.w #6,dx and it provides convenient safety space for all sorts of actions.

That results under normal circumstances (i.e. OCS/ECS) in a modulo like: 64-40.
In the case of the 64 bit fetch I my modulos are set: 64-40-8 while the Data Fetch Stop is set to $d0.
And all is looking fine at the moment. Can't say anything about the speed because I'm a dummy in those things.
I'm probably wasting cycles all over the place.