Quote:
|
Originally Posted by Codetapper
Are you sure the modulo for source A in the restore part shouldn't be 0? If you're effectively saving the background that is going to be destroyed to a buffer, it's likely to be a continuous buffer in memory so no modulo on the A channel.
Can you attach your source code so we can see everything in that routine? Is your sprite on a word boundary itself - ie. up against the far left? What minterms are you using? (I think source would be easier to look at!)
Also pictures of the screen before the screen restore, after screen restore, after new blit etc would be useful if you can do that.
|
I'm actually blitting from a 320 x 224 background screen to the screen (which is also 320 x 224)
* D0 - Bitplane mod value
* D1 - Blitsize
* A0 - Back pointer
* A1 - Screen pointer
BlitBack:
jsr BlitterWait
* Set Source A first and last word mask
move.l #0xFFFFFFFF, BLTAFWM
* Set Source A modulo
move.l d0, BLTAMOD
* Set Dest D modulo
move.l d0, BLTDMOD
* Set blitter control bits
move.l #0x09F00000, BLTCON0
* Do 5 bitplanes
move.l #(5-1), d7
BlitBackLoop:
jsr BlitterWait
* Set Source A
move.l a0, BLTAPT
* Set Dest D
move.l a1, BLTDPT
* Blit start and size
move.w d1, BLTSIZE
* Advance to next bitplane
add.l #PLANESIZE, a0
add.l #PLANESIZE, a1
dbra d7, BlitBackLoop
rts
PLANESIZE is 320 * 224 / 8
D0 is 36
D1 is 0x0402 (I've also tried 0x0401 and 38 for Mod value, since I'm not using a shift)
A0 is the background data (320 x 224 x 5) allocated as CHIP
A1 is the screen (320 x 224 x 5) allocated as CHIP
You can download the program from
http://www.emuvibes.com/Frog.zip. It uses the A button and not start as shown on the screen, this allows testing in WinUAE.
This is setup as a CDTV bootable CD, although all testing is done on the WinUAE CD32 configuration in NTSC. The BlitBack is changed to point A0 to the top of the background data before entering the BlitBackLoop. This make the area that is blitted more obvious.
I'm hoping that this isn't just a bug in WinUAE.