Double question about saving background

[nandius_c]

Hi everyone,

As I said in earlier posts I'm developing a simple arkanoid type game for Amiga in assembly. I would like to ask you a couple of questions about saving the background before drawing a bob:

1) Which is the best way to manage the save buffer allocation? I think that could be calling Exec to allocate the memory needed each time you have to save background for a bob and keep the pointer returned by that call as part of the bob data. Do you think there is a better way of doing this?

2) Here comes the tricky one... Something I couldn't solve properly. I have a 320x200 background with 4 bitplanes. I want to save a 16x8 area of this background before drawing a bob of that size. Problem is that this bob has to be drawn to an odd memory address. I thought I had solved it using some negative modulos. It seemed to work on paper but when I implemented it, to my surprise, it didn't work. After reading again 'Blitter hardware' in Amiga Hardware Reference Manual I realised it wouldn't work because of the blitter working as 2 chips connected by a pipeline. Here is the not working source code:

saveBrickBackgroundNotEven:
move.l a5,-(a7)

lea.l _custom,a5

move.w #$07CA,bltcon0(a5) ;enable B, C and D, A*B + ¬A*C
move.w #$8000,bltcon1(a5) ;B shift 8 right
move.w #$0000,bltafwm(a5) ;first word mask
move.w #$FFFF,bltalwm(a5) ;last word mask

move.w #$FFFF,bltadat(a5) ;A channel contains mask in data register

move.l a0,bltbpt(a5) ;B channel points to screen
move.w #36,bltbmod(a5) ;40 bytes per bitplane and line
;4 bytes read per bitplane and line
;40 - 4 = 36

move.l a1,bltcpt(a5) ;C channel points to save buffer
move.w #-2,bltcmod(a5) ;go 2 bytes back because we read 4

move.l a1,bltdpt(a5) ;D channel points to save buffer
move.w #-2,bltdmod(a5) ;go 2 bytes back because we read 4

move.w #$0802,bltsize(a5) ;8 lines high
;1 word wide (+1 extra word for shift)
.saveBrickBackgroundNotEvenEnd:
move.l (a7)+,a5
rts

So, I haven't been able to save the background using a 16x8x4 save buffer. The only way I could finaly do it was using a 32x8x4 save buffer, copying 2 words instead of one: the object but also the byte before (that's in an even address) and after it. Here is my final solution, but would it be possible using a buffer same size of the source area though it's at an odd address?

saveBrickBackgroundNotEven:
move.l a5,-(a7)

lea.l _custom,a5

move.w #$09F0,bltcon0(a5) ;enable A and D, direct copy = $F0
move.w #$0000,bltcon1(a5) ;no special modes
move.w #$00FF,bltafwm(a5) ;first word mask
move.w #$FF00,bltalwm(a5) ;last word mask

move.l a0,bltapt(a5) ;A channel points to screen
move.w #36,bltamod(a5) ;40 bytes per bitplane and line
;4 bytes read per bitplane and line
;40 - 4 = 36

move.l a1,bltdpt(a5) ;D channel points to save buffer
move.w #0,bltdmod(a5)

move.w #$0802,bltsize(a5) ;8 lines high x 4 bitplanes per line
;2 words wide
.saveBrickBackgroundNotEvenEnd:
move.l (a7)+,a5
rts

I'm sorry about any mistake in my explanation, hope it's complete enough... Any help on any or all of these 2 questions appreciated.

Thanks in advance!

[Codetapper]

Personally I wouldn't bother with all the complications of saving just the width behind the object. If the object is always 16 pixels wide, then 32 pixels will always save the entire background, so just do that.

You should be able to take the coordinate (let's say it's 46 pixels indented), mask off the low bits (with and.w #$fff0,d0) which would give the value 32. Now you divide by 8 (with shifts) so you need to skip 4 bytes, and then simply save your 4 bytes across, skipping (40 - 4 = 36) bytes between each plane. And leave the masks as $ffff for both first and last word mask. Done!

[nandius_c]

Originally Posted by Codetapper

Personally I wouldn't bother with all the complications of saving just the width behind the object. If the object is always 16 pixels wide, then 32 pixels will always save the entire background, so just do that.

You should be able to take the coordinate (let's say it's 46 pixels indented), mask off the low bits (with and.w #$fff0,d0) which would give the value 32. Now you divide by 8 (with shifts) so you need to skip 4 bytes, and then simply save your 4 bytes across, skipping (40 - 4 = 36) bytes between each plane. And leave the masks as $ffff for both first and last word mask. Done!

OK, thanks for your answer! But what if the game has a lot of bobs on screen? It would need double amount of memory for save buffers, don't you think that could be important in some kind of games? I would like to make my game for A500, 512k (if possible) and that's why I'm worried about wasting memory the way I'm implementing save buffers right now. Also if there's a way of solving this problem properly I would like to know it as I could use it for future games.

[Codetapper]

Originally Posted by nandius_c

OK, thanks for your answer! But what if the game has a lot of bobs on screen? It would need double amount of memory for save buffers, don't you think that could be important in some kind of games? I would like to make my game for A500, 512k (if possible) and that's why I'm worried about wasting memory the way I'm implementing save buffers right now. Also if there's a way of solving this problem properly I would like to know it as I could use it for future games.

It doesn't use double the memory, it uses an extra 2 bytes per line for the benefit of faster blits, as you can restore the background for any object with a simple D=A blit. No masking or shifting is needed so the code to do the blit is simplified and standard for any object. A 128 pixel wide object would only need 2 extra bytes. If you have a width like 13 pixels wide and indented by 5 pixels, you don't need to worry about masks which is worth the few wasted bytes imho!

[nandius_c]

Originally Posted by Codetapper

It doesn't use double the memory, it uses an extra 2 bytes per line for the benefit of faster blits, as you can restore the background for any object with a simple D=A blit. No masking or shifting is needed so the code to do the blit is simplified and standard for any object. A 128 pixel wide object would only need 2 extra bytes. If you have a width like 13 pixels wide and indented by 5 pixels, you don't need to worry about masks which is worth the few wasted bytes imho!

In my case it's double the memory because the objects I'm blitting are 2 bytes wide, hehe. I totally agree with you, I was worried about not implementing this properly but now I see that I wasn't so wrong . Anyway, if anybody wants to give another point of view, I would be glad to know it.

@Codetapper: thank you so much for your help and I hope to see updates in your awesome site. I also started using Maptapper recently and I think it's a fantastic tool. Thanks!

[Photon]

If your background doesn't change and you have plenty of chipmem left, just copy the entire background after the screen is setup. Then you can skip the save background step.

If you don't have enough chipmem and need to save the background:

Modulos must be even, because the blitter only works with words. This means widths must be rounded up to the next even 16px - but if the bob shift is 0, you don't have to add one word to the width. Another way to save to memory spent is to only save away the bitplanes of the background that are changed when you blit the bob. So if the background is 3 bitplanes and the bob is 5 bitplanes, you can save away just 3 and clear the other two bitplanes.