Show BOB

[geldo79]

I have a question concerning blitting a bob (raw normal, 4 bitplanes) into a destination (also 4 bitplanes, 320x256 pixels). My BOB has 16x16 pixels. I use a cookie cut blitter logic function ( $ca ). I thought I should set the following parameters:

Modulo for channel a (mask) : 0
Modulo for channel b (bob) : 0
Modulo for channel c (background) : 38 bytes
Modulo for channel d (dest.) : 38 bytes.
BLTSIZE: (64×16)+1

Using these parameters, no BOB is shown on the screen.

But, it works if i set the modulo for a and b to -2, and the BLTSIZE to (64x16)+2.

Why?

Greetings Christian

[Auscoder]

Ensure width is in words, and modulo is in bytes. It should look clear then.

Are you using barrel roll/shifting? Adding one additional word (requires -2 bytes to modulo and +1 word to blitWidth)

[mcgeezer]

You'll need to set BLTFWM and BLTLWM to -1.

This is the First and last word masks of the rectangle... in your case you only have one word and if it is 0 then no bits will be passed through.

A quick snippet of how I do it with barrel shifter.

  WAIT_FOR_BLITTER
                move.w  d4,BLTCON0(a5)
                move.w  d3,BLTCON1(a5)

                move.l  #$ffff0000,BLTAFWM(a5)      ; Only want the first word
                ;move.w  #$0,BLTALWM(a5)         ; Dump the last word

                move.w  #SPRITE_ASSETS_SIZE_X-4,BLTAMOD(a5)
                move.w  #SPRITE_ASSETS_SIZE_X-4,BLTBMOD(a5)
                move.w  #PLAYFIELD_SIZE_X-4,BLTCMOD(a5)
                move.w  #PLAYFIELD_SIZE_X-4,BLTDMOD(a5)

		move.w	#(16*5)<<6+2,d3
                move.w  d3,(a0)                 ; Store Blit Size

                move.l  a3,BLTAPTH(a5)          ; Load the mask address
                move.l  a2,BLTBPTH(a5)          ; Sprite address
                move.l  a1,BLTCPTH(a5)          ; Destination background
                move.l  a1,BLTDPTH(a5)
                move.w  d3,BLTSIZE(a5)

[Tigerskunk]

Originally Posted by geldo79

I have a question concerning blitting a bob (raw normal, 4 bitplanes) into a destination (also 4 bitplanes, 320x256 pixels). My BOB has 16x16 pixels. I use a cookie cut blitter logic function ( $ca ). I thought I should set the following parameters:

Modulo for channel a (mask) : 0
Modulo for channel b (bob) : 0
Modulo for channel c (background) : 38 bytes
Modulo for channel d (dest.) : 38 bytes.
BLTSIZE: (64×16)+1

Using these parameters, no BOB is shown on the screen.

But, it works if i set the modulo for a and b to -2, and the BLTSIZE to (64x16)+2.

Why?

Greetings Christian

Like Auscoder said, you are probably using a barrell roll (the -2 source modulo indicates that), which means you need to add an additional word to your blit size (+2 instead of +1).

[geldo79]

Ah....ok. Thanks. Yes, I use the barrel roll for setting the bob at a position (x,y). Thus, I can understand why the code is written that way. But the routines for buffering and clearing the bob don't work properly now. Maybe someone could have a look at the code. The Bob appears nicely at position (x,y), but it does not disapper when the bob is moved.

Set_Bob:

* d1 = x, d3 = y

move.l BITPLANE,a0
move.w d3,d0
mulu.w #40,d0
add.w d0,a0

move.w d1,d0
move.w d0,d1
and.w #$000f,d0
lsl.w #8,d0
lsl.w #4,d0
move.w d0,d2

or.w #$0FCA,d0
lsr.w #3,d1

and.w #$fffe,d1
add.w d1,a0

lea BOB,a1 ; 16x16 (4 Bitplanes) Raw-Normal
moveq #4-1,d7
PlaneLoop:
btst #6,2(a5)
WBlit2:
btst #6,2(a5)
bne.s WBlit2

move.l #$ffff0000,$44(a5)

move.w d0,$40(a5)
move.w d2,$42(a5)


move.w #40-4,$60(a5)
move.w #-2,$62(a5)
move.w #-2,$64(a5)
move.w #40-4,$66(a5)


move.l #Mask,$50(a5)
move.l a0,$54(a5)
move.l a0,$48(a5)
move.l a1,$4c(a5)
move.w #(16*64)+2,$58(a5)

lea 2*16(a1),a1

lea 40*256(a0),a0
dbra d7,PlaneLoop

rts


***************************************************



Buffer_Bob:


* d1 = x, d0 = y

move.l BITPLANE,a0 ;

mulu.w #40,d0

add.w d0,a0

lsr.w #3,d1
and.w #$fffe,d1
add.w d1,a0

lea Buffer,a1
moveq #4-1,d7
PlaneLoop2:
btst #6,2(a5)
WBlit3:
btst #6,2(a5)
bne.s WBlit3

move.l #$ffffffff,$44(a5)


move.l #$09f00000,$40(a5)


move.w #40-4,$64(a5)
move.w #0,$66(a5)

move.l a0,$50(a5)
move.l a1,$54(a5)
move.w #(64*16)+2,$58(a5)

lea 40*256(a0),a0
lea 4*16(a1),a1

dbra d7,PlaneLoop2

rts

****************************************************

Clear_Bob:

* d1 = x, d0 = y

move.l BITPLANE,a0

mulu.w #40,d0
add.w d0,a0

lsr.w #3,d1
and.w #$fffe,d1
add.w d1,a0


lea Buffer,a1
moveq #4-1,d7
PlaneLoop3:
btst #6,2(a5)
WBlit4:
btst #6,2(a5)
bne.s WBlit4

move.l #$ffffffff,$44(a5)

move.l #$09f00000,$40(a5)

move.w #40-4,$66(a5)
move.w #0,$64(a5)

move.l a1,$50(a5)
move.l a0,$54(a5)
move.w #(64*16)+2,$58(a5)

lea 40*256(a0),a0
lea 4*16(a1),a1

dbra d7,PlaneLoop3
rts

***********************************

Mask:

dc.w %0000001111000000
dc.w %0000111111111000
dc.w %0001111111111100
dc.w %0011111111111110
dc.w %0011111111111110
dc.w %0111111111111111
dc.w %0111111111111111
dc.w %0111111111111111
dc.w %0111111111111111
dc.w %0111111111111111
dc.w %0011111111111110
dc.w %0011111111111110
dc.w %0001111111111100
dc.w %0000111111111000
dc.w %0000001111000000
dc.w %0000000000000000

********************************

SECTION BUFF,BSS_C

Buffer:
ds.w 16*2*4

[Tigerskunk]

Of course it doesn't disappear.
This is not a sprite. A BOB is being blitted, which means you are copying data into your bitplanes. It doesn't magically disappear just because you are copying the same data into some other location there...

You need to restore that part of the bitplane. There are different approaches to this.
Check out "triple buffering", for instance...

edit: it's early in the morning, I didn't read your whole text.. Will have a look at it now...

[geldo79]

Originally Posted by Steril707

Of course it doesn't disappear.
This is not a sprite.

Unfortunately. Sprites already work in my game (for which i started coding 10 years ago or so....and ended coding 9 years ago ) I'd like to continue my work now, and for that I need to know how the blitter works. I have taken this code from an asm tutorial. Maybe you can tell me what's wrong with it. I have to say, I don't understand that barrel roll completely. Computing the x and y and shifting values....ok. But when I use the shifting for a 16x16 BOB, do I rather have to use a BOB of width 32 then, containing an empty area, where the BOB can be shifted in?

[Tigerskunk]

Yep. That's how it works..
Also, personally I prefer to have some constants for the custom chip Adresses (i.e. "BLTSIZE" or "DMACON"). Seems a lot more readable to me than those offsets that you are using..

[Rotzloeffel]

Originally Posted by Steril707

edit: it's early in the morning, I didn't read your whole text..

Don´t drink in the Train (Insider)

[mcgeezer]

When i’m in the airport lounge i will take another look at the code...
But be aware that doing a

Add.w d0,a0

Is suicide.

You want to make that an add.l

Address regs can be treated as data regs as well.

Geezer

[DanScott]

Originally Posted by mcgeezer

But be aware that doing a

Add.w d0,a0

It's controlled suicide

as long as you know your range is within a word, you are usually fine (D0 is sign extended before being added as a long to A0 AFAIK)

[geldo79]

Well...maybe the whole thing did not work because I did not use a 16*32 BOB, but a 16x16 BOB. But it looked like the BOB was shown correctly on the screen.....

[ross]

Originally Posted by DanScott

It's controlled suicide

To be more precise, in this case, is an y>=820 controlled suicide

[ross]

Originally Posted by geldo79

Well...maybe the whole thing did not work because I did not use a 16*32 BOB, but a 16x16 BOB. But it looked like the BOB was shown correctly on the screen.....

Just a tip. The routines for themselves might also work, but you have to describe how and when you use them.
It's very difficult to help you without context.

[mcgeezer]

Originally Posted by ross

To be more precise, in this case, is an y>=820 controlled suicide

Originally Posted by DanScott

It's controlled suicide

as long as you know your range is within a word, you are usually fine (D0 is sign extended before being added as a long to A0 AFAIK)

Yup, and here be the tale.

My screen buffers were $AF00 (44Kb) in size (40 bytes wide x by 224 scan lines of 5 bitplanes).

When I plot a sprite I typically save an offset from the top of the buffer, so much to my surprise of not knowing how add <dn>,<an> really worked whenever a sprite was being plot or restored toward the bottom of the buffer it was wrapping and shitting over a lower memory segments. And of course, the problem was that when the word value had the MSB set then this odd bug surfaced.

It took me a while to figure it out, but... it was a lesson learned for me... don't use add.w <dn>,<an> EVER unless I have cause to.

[roondar]

Am I missing something here?
I thought adding a 16 bit signed value to an address register using add.w was safe?

Or is the lesson here that you can forget that the value needs to be in that range for it to work and therefore need to be very careful?

[ross]

Originally Posted by roondar

Am I missing something here?
I thought adding a 16 bit signed value to an address register using add.w was safe?

Or is the lesson here that you can forget that the value needs to be in that range for it to work and therefore need to be very careful?

Hi roondar, the problem here is on two levels: conceptual and practical.
Before the add.w there is a mulu.w that span the unsigned result over 32 bit in selected data register.
adda.w or adda.l to Ax take the same cycles because of the sign extension.
Furthermore, nothing prevents you from having bit 15 = 1 as a valid result in Dx, and if this the case you have a negative value added to register Ax...

Yes, this is a controlled case given the limited values of y, but it is the best way to have future unexpected behaviors from your code.

[roondar]

Huh, I thought adda.w was ever so slightly faster...

Anyway, thanks for the explanation. Makes sense to use .l in all cases if they're the same speed anyway (unless you are naughty and don't clear the top bits of Dx first ).

I know mulu.w does that, but I have had some code misbehave on several occasions because I did a word calculation and assumes a zero top word for a later add.l.

[ross]

Originally Posted by roondar

Huh, I thought adda.w was ever so slightly faster...

It depends.

For the data direct cycles are the same but for register indirect.

For example, take this LUT access code:
adda.w (a0)+,a1
adda.l (a0)+,a1

Two advantages for the first case:
faster (you have a single access when 16 bit memory)
smaller (table is half in memory)

[geldo79]

My BOB buffer/set/clear works now! There was one line, where a "bsr.w Clear_Bob" was written as "lsr.w Clear_Bob"

Anyway.....I tested again using only 16x16 Bob size, without an empty area to the right where i can shft in the Bob. But it works, when setting the modulos in the Set_Bob method to -2. Thus, I do not have to use a width of 32 for using the barrel shift?! The Bob is perfectly shown on any x,y combination.