Quick blitter refresher please!

jimmy2x2x · 05 December 2014, 10:03

I'm plodding away at my bruce Lee project and have been using hardware sprites exclusively up until now, the time has come to use the blitter! I haven't touched it for decades and was hoping for a quick refresher, pretty please ☺ Maybe something like a simple straight memory copy would be great, although any well documented source would be useful. Thanks!

pmc · 05 December 2014, 12:17

Don't usually come here anymore but spotted this on an infrequent visit and so, for old times sake:

Wait for blitter to be ready (might also be worth setting blitter priority bit first in dmacon (not shown in snippet below)):

Code:

.wait:    btst.b    #6,$dff002
            bne.b    .wait

then set required bits of blitter control regs, masks, modulos and pointers as relevant for the blit you want to do and then write to blitsize reg ($dff058) to set the blit running.

All very straightforward - check the well written docs as per the (what else...?) Hardware Ref Manual

phx · 05 December 2014, 13:22

Quote:

Originally Posted by jimmy2x2x

Maybe something like a simple straight memory copy would be great,

For a simple memory copy on word-boundaries you would use channel A and D, which is the fastest mode. You have to set up BLTAFWM and BLTALWM to $ffff, turn on DMA for channel A and D in BLTCON0, clear BLTCON1, BLTAMOD, BLTDMOD, write the source pointer to BLTAPT and the destination pointer to BLTDPT and finally start with blit with writing the size to BLTSIZE.

In most cases you want to copy to a bitmap, so you need to set up the modulos (e.g. BLTDMOD = bytes_per_row - image_width). And when you want to blit to a not-word-aligned position in the bitmap then you have to shift the input stream by 0-15 bits. This requires to read/write one additional word per line to give room for the right-shifted bits (in ascending mode). You also need masking.

Quote:

although any well documented source would be useful.

Here is a simple example to copy a masked image into a bitmap. BPR defines the number of bytes per row in the bitmap. YOffTab is a table with bitmap offsets for each row (y*BPR). The WAITBLIT macro may be similar to the code pmc has given.

Code:

bltmasked:
; Copy a word-aligned, masked image to a bitmap position.
; Doesn't check whether height is greater than 1024!
; d0.w = xpos
; d1.w = ypos
; d2.w = width in words
; d3.w = height in lines (multiplied by PLANES for interleaved bitmaps)
; a0 = destination View's bitmap
; a1 = image pointer
; a2 = image mask pointer

        movem.l d2-d3/a3,-(sp)

        lsl.w   #6,d3
        addq.w  #1,d2                   ; extra word for shifting
        or.w    d2,d3
        swap    d3
        move.w  d2,d3
        add.w   d3,d3                   ; d3 BLTSIZE | width in bytes

        ; add ypos to bitmap pointer
        lea     YOffTab(a4),a3
        add.w   d1,d1
        add.w   d1,d1
        add.l   (a3,d1.w),a0

        ; make BLTCON0, BLTCON1
        moveq   #15,d2
        and.w   d0,d2
        ror.w   #4,d2                   ; ASH, BSH
        move.w  d2,d1
        or.w    #$0fca,d1               ; use ABCD, D=AB+/AC
        swap    d1
        move.w  d2,d1                   ; d1 BLTCON0 | BLTCON1

        ; add xpos to bitmap pointer
        asr.w   #4,d0
        add.w   d0,d0
        add.w   d0,a0                   ; a0 bitmap pointer

        ; BLTBMOD is -2, because we read an additional word for shifting.
        ; BLTCMOD and BLTDMOD are BPR - (width in bytes)
        moveq   #BPR,d0
        sub.w   d3,d0
        swap    d0
        subq.w  #2,d0                   ; d0 BLTCMOD | BLTBMOD

        moveq   #-1,d2
        clr.w   d2                      ; d2 BLTAFWM=$ffff | BLTALWM=$0000
        swap    d3                      ; d3 BLTSIZE
        move.l  a0,a3

        ; copy masked image
        WAITBLIT
        move.l  d0,BLTCMOD(a6)
        swap    d0
        move.l  d0,BLTAMOD(a6)
        movem.l d1-d2/a0-a3,BLTCON0(a6)
        move.w  d3,BLTSIZE(a6)

        movem.l (sp)+,d2-d3/a3
        rts

When using the Blitter it is recommended to do all calculations before waiting and then write all registers as quickly as possible.

BippyM · 05 December 2014, 13:23

Why do you not visit pmc? (soorry for OT post)

Photon · 05 December 2014, 15:27

Seemed like a good topic for Coppershade, so I added it. It should get you started. Hope you like it!

> Programming the Blitter

jimmy2x2x · 05 December 2014, 16:55

Brilliant support, that's why I love this forum. Thanks very much guys, it would be easy to give up re-learning the Amiga on my own. I will try and get some useful blits working tonight!

Lonewolf10 · 05 December 2014, 22:01

Quote:

Originally Posted by bippym

Why do you not visit pmc? (soorry for OT post)

I was going to ask that too, then realised he probably won't see the message for months (if at all).

Quote:

Originally Posted by Photon

Seemed like a good topic for Coppershade, so I added it. It should get you started. Hope you like it!

Always good to have a reference from the pro's as a reminder/fresher

jimmy2x2x · 06 December 2014, 00:26

Getting somewhere how, got the blitter doing some of the heavy lifting! Quick question about bobs or software sprites, do you need to store them with a separate mask or is that only of you want to display color0, and do you need to store a blank 16 pixel area (word aligned) with the sprite data? I'm working through the provided documentation, cheers

Leffmann · 06 December 2014, 11:16

Unless the shape of your sprite is a solid rectangle, you will need to store a mask for it. You can generate the mask at startup however, if you can make use of color-keying and say that f.ex color 15 indicates transparency. Also, if you're doing interleaved blits then you will have to duplicate the mask for each bitplane.

The so called "Blitter words" is a solution to a non-existing problem, and misinformation that has been kept alive in the Amiga programming community since forever. The intended way is to put the mask in source A and cut off that 16-pixel area on the right by setting the source A mask value to $FFFF 0000 and subtracting 2 from the source A and B modulos, just like in phx's code example.

jimmy2x2x · 06 December 2014, 18:12

Thanks, I'm getting my head around it slowly, it's been a while and the old grey matter isn't what it used to be!

jotd · 18 November 2019, 00:08

Interesting thread. I didn't know how to program the blitter at all one month ago and now I'm able to blit an image to a screen, with or without 0-15 shifting. Using only A src & D (of course)

There are several things I have to improve, for instance, blitting only a part of the source image (clipping), I think I can manage it

One thing I can't figure out how to do / how it works is: how to handle "transparency".

I've searched around, and it seems to involve "minterms" or something like that but I'm not sure.

In my case, I have converted png images to raw data (using the excellent amigeconv), aligning/adding 16 bits when the bobs can possibly be copied with shifting (for instance, background images don't need adding 16 bits, since they're pasted at X=0)

That works well. Now, having set black as the first color (so all bits off = black) I'd like to use this color as "transparent" (else if I blit my bob on a background, the black border appears: I want this border gone, like sprite do)

If I use ORing on the bitplanes independently, the colors are going to be modified. That's the main thing I don't understand.

ATM if I had to do that I would:

1) blit 1 plane in XOR mode to turn off all bits from all destination bitplanes. This plane would have to be a ORed version of all source bitplanes.
2) blit all source planes in OR mode into destination

This seems a bit clumsy, and doesn't use B & C sources. Is there a better way, someone can share code?

mcgeezer · 18 November 2019, 00:17

Quote:

Originally Posted by jotd

Interesting thread. I didn't know how to program the blitter at all one month ago and now I'm able to blit an image to a screen, with or without 0-15 shifting. Using only A src & D (of course)

There are several things I have to improve, for instance, blitting only a part of the source image (clipping), I think I can manage it

One thing I can't figure out how to do / how it works is: how to handle "transparency".

I've searched around, and it seems to involve "minterms" or something like that but I'm not sure.

In my case, I have converted png images to raw data (using the excellent amigeconv), aligning/adding 16 bits when the bobs can possibly be copied with shifting (for instance, background images don't need adding 16 bits, since they're pasted at X=0)

That works well. Now, having set black as the first color (so all bits off = black) I'd like to use this color as "transparent" (else if I blit my bob on a background, the black border appears: I want this border gone, like sprite do)

If I use ORing on the bitplanes independently, the colors are going to be modified. That's the main thing I don't understand.

ATM if I had to do that I would:

1) blit 1 plane in XOR mode to turn off all bits from all destination bitplanes. This plane would have to be a ORed version of all source bitplanes.
2) blit all source planes in OR mode into destination

This seems a bit clumsy, and doesn't use B & C sources. Is there a better way, someone can share code?

When you say transparency I'm assuming you mean to Cookie Cut, where a straight copy is minterm $9f0 the cookie cut mode is $fca.

Have a read of this...

http://amigadev.elowar.com/read/ADCD.../node011F.html

You have to feed the blitter with a mask of your sprite through channel A, you feed your actual bob bitmap through channel B, and you feed your pristine background through channel C.

If you are stuck let me know and I'll help you further.

Geezer

Antiriad_UK · 18 November 2019, 03:50

I find it impossible to comprehend that you can fix whdload slaves that appear like witchcraft to me but don’t do blitter masks.

I understand the page mcgeezer shows the HKRM but also remember that it made no sense to me at the time. And also made no sense to me recently. I’m dumb as fuck clearly. But cookie cut minterms is what you need :£

I’ve always liked the blitter truth table way of working where you draw up the
A and B and C diagram and work out how to merge them together into a D. So even if you don’t understand what you are doing you can get the result you want.
But in this case you need to come up with a “mask” or new solid shape that lets you say where is solid and where is transparent.

If you have a raw image and you try and blit that to a screen. Yep you are going to obliterate the existing picture. But if you just OR it to the screen (A OR B = D) you will also mess it up because you will create new colours. The cookie cut thing is where you have to create a whole new single bpl “shape” that you apply to all operations. Usually it will be a solid shape that only has holes (00s)
where you want transparency. Most of the iff to raw software (like piccon) will create a raw image that has this mask per bpl automatically. It really needs a diagram. Someone somewhere must have done it?!!

The you use a minterm that says something like D equals A (bob data) OR B (existing screen data) AND C (a mask). So if the mask is 1 ( the big solid outline of the shape) then you pass through the A/bob data. If the mask is 0 then you ignore the Bob data and just use the existing B(current screen) data ( transparency) The thing to understand is that you need a generated mask to make this work. Just converting an image to raw doesn’t get you that. The conversion also has to look at all the bitplanes and then generate an appropriate mask set of bitplanes. Your conversion software of choice will usually mention masks - this is what they mean.

I was exceptionally drunk when I wrote this and just read it back and it made no sense. But i think when I can form a blitter truth table in the morning or when mcgeezer explains it properly we will get there

(I also may have reversed B and C for the usual $fca = cookie cut minterm)

DanScott · 18 November 2019, 10:12

A and B will be your source bob & mask (as those are the 2 channels that you can shift)

mcgeezer · 18 November 2019, 10:18

As i need to explain this in my game dev series anyway i’ll try and do some power point slides tonight that make it all clear.

jotd · 18 November 2019, 11:29

@Antiriad_UK yeah, incredible right?

I've fixed blitter issues where I saw blitter writes and all, I've fixed a lot of CPU issues, copperlist issues, display, etc... but never really tried to understand the details of the blitter (or playfields, or sprites). Don't worry I'm a quick learner once I put my mind to it and with help of this wonderful forum!

thanks for all this. $9F0 rings a bell (the value I'm currently using) and I'll try cookie cut after having masked source planes together to use as B source. I think I'll manage.

when you read blitter "tutorials" they explain you all the minterm equation shit and you don't understand anything practical. Okay I can mask/shift and test XOR/AND at the same time on 3 different planets but I just wanted to paste an image...

Antiriad_UK · 18 November 2019, 12:13

@Dan, yeah sorry A and B for Bob/Mask, C for screen

@mcgeezer, would be a great thing to cover properly for sure. But until then have some ascii art!

I used to do all this stuff with tables like described in in HKRM http://amigadev.elowar.com/read/ADCD.../node011C.html
Some examples always help though.

Just copy this table into your source code. Bascially we use it do come up with what you want D, your destination, to be. It describes a byte (the minterm) with the MSB, bit 7, at the bottom.

Code:

; A B C  D   Bit Number
; 0 0 0      0
; 0 0 1      1
; 0 1 0      2
; 0 1 1      3

; 1 0 0      4
; 1 0 1      5
; 1 1 0      6
; 1 1 1      7

Easiest example is $f0 (straight copy from A to D). This would be used if you want to copy something to the screen and obliterate what is there already. Mostly used for printing fixed width fonts or scrolly messages.

If you aren't using a channel then just delete/or cross it out and ignore it for your calculcations. So for copy we only care about A and D:

Code:

; A B C  D   Bit Number
; 0 x x      0
; 0 x x      1
; 0 x x      2
; 0 x x      3

; 1 x x      4
; 1 x x      5
; 1 x x      6
; 1 x x      7

Then fill in the D column. For a copy we want D to equal A. If A is 1 then we want to output to be 1. If A is 0 then the output should be 0. Fill that in:

Code:

; A B C  D   Bit Number
; 0 x x  0   0
; 0 x x  0   1
; 0 x x  0   2
; 0 x x  0   3

; 1 x x  1   4
; 1 x x  1   5
; 1 x x  1   6
; 1 x x  1   7

Reading the D column from the bottom gives us our minterm %1111000 or $f0.

Next example, you'll have seen this minterm often as well. Let's say you want to take your bob and OR/merge it with the screen.

Let's use A for BOB, B for screen, D for final screen value, and fill in the table. We want D to be 1 if either the BOB or the screen is 1 (A OR B)

Code:

; A B C  D   Bit Number
; 0 0 x  0   0
; 0 0 x  0   1
; 0 1 x  1   2
; 0 1 x  1   3

; 1 0 x  1   4
; 1 0 x  1   5
; 1 1 x  1   6
; 1 1 x  1   7

That gives us %11111100, $fc. I bet you've seen $fc a lot

You might be tempted to just do this with your multi-bitplane BOBs, but then you notice the colors go all crazy. Imagine a small diamond shape in 2 bitplanes. Let's have the left half in colour01 (1s set on bpl1) and the right half in color02 (1s set on bpl2)

Code:

If you just use the A OR B minterm with this kind of image then if there is already data on the screen then when you blit your color01 on bitplane 1 then if bitplane 2 already has some data there then you are going to end up with color03 there. Not what we want at all.

This assumes non-interleaved screen as it's easiest to explain first. We are blitting on 2 bitplanes, but the cookie/mask shape would be the same for both - we want an outline of the diamond shape for our mask. This is where the cookie term comes from, we are cutting out a shape.

Code:

A is the mask, B is the BOB, C is the screen, D is the final screen. Basically we only "let" the BOB data influence the final screen data when the mask is 1. When the mask is 0 then we leave the screen alone. When mask is 1 and BOB is 1 then we write 1 to the screen. When mask is 1 and BOB is 0 we CLEAR the screen

Code:

; A B C  D   Bit Number
; 0 0 0  0   0
; 0 0 1  1   1
; 0 1 0  0   2
; 0 1 1  1   3

; 1 0 0  0   4
; 1 0 1  0   5
; 1 1 0  1   6
; 1 1 1  1   7

Minterm is %11001010 or $ca

You do two blits, one for bpl1 and the mask, then one for bpl2 with the same mask.

Does that make any sense at all, or is it worse now ?

These days I use the assembler to generate the minterm like this (seems I was the last person to figure this out lol). This is my vertical fill minterm which is A XOR B. The BLTEN values are from my standard macros. There seems to be similar values in the CBM includes in hardware/blit.i

Code:

;Blitter logic macros
;& (bitwise and) 
;^ (bitwise exclusive-or) 
;| (bitwise inclusive-or) 
;! (bitwise not)
BLTEN_A		= $0800
BLTEN_B		= $0400
BLTEN_C		= $0200
BLTEN_D		= $0100
BLTEN_AD	= (BLTEN_A|BLTEN_D)
BLTEN_ABD	= (BLTEN_A|BLTEN_B|BLTEN_D)
BLTEN_ACD	= (BLTEN_A|BLTEN_C|BLTEN_D)
BLTEN_ABCD	= (BLTEN_A|BLTEN_B|BLTEN_C|BLTEN_D)

BLT_A	= %11110000
BLT_B	= %11001100
BLT_C	= %10101010

;Example use for A XOR B
;move.w	#$0d3c,bltcon0(a6)
move.w	#BLTEN_ABD+(BLT_A^BLT_B),bltcon0(a6)

jotd · 18 November 2019, 22:36

that makes a lot of sense. I'm using amigeconv which does NOT create the extra mask "bitplane" but I'm also hacking the converted "raw" format to add dimensions, number of planes (header), so I can also read bitplane data, OR them together and add the last bitplane, or just generate it when I read the data (which is less flexible as if we need a real black and not transparent we can't do that)

Thanks. I'll test that when I have the time. Too much work/family/sports/other ATM...

BippyM · 18 November 2019, 22:44

What's abcd?

Antiriad_UK · 18 November 2019, 23:01

Quote:

Originally Posted by BippyM

What's abcd?

Blitter can take up to 3 inputs (A B and C) and has 1 output which is D.

18 November 2019, 12:13	#17
Antiriad_UK Registered User Join Date: Mar 2019 Location: Birmingham, UK Posts: 142	@Dan, yeah sorry A and B for Bob/Mask, C for screen @mcgeezer, would be a great thing to cover properly for sure. But until then have some ascii art! I used to do all this stuff with tables like described in in HKRM http://amigadev.elowar.com/read/ADCD.../node011C.html Some examples always help though. Just copy this table into your source code. Bascially we use it do come up with what you want D, your destination, to be. It describes a byte (the minterm) with the MSB, bit 7, at the bottom. Code: ; A B C D Bit Number ; 0 0 0 0 ; 0 0 1 1 ; 0 1 0 2 ; 0 1 1 3 ; 1 0 0 4 ; 1 0 1 5 ; 1 1 0 6 ; 1 1 1 7 Easiest example is $f0 (straight copy from A to D). This would be used if you want to copy something to the screen and obliterate what is there already. Mostly used for printing fixed width fonts or scrolly messages. If you aren't using a channel then just delete/or cross it out and ignore it for your calculcations. So for copy we only care about A and D: Code: ; A B C D Bit Number ; 0 x x 0 ; 0 x x 1 ; 0 x x 2 ; 0 x x 3 ; 1 x x 4 ; 1 x x 5 ; 1 x x 6 ; 1 x x 7 Then fill in the D column. For a copy we want D to equal A. If A is 1 then we want to output to be 1. If A is 0 then the output should be 0. Fill that in: Code: ; A B C D Bit Number ; 0 x x 0 0 ; 0 x x 0 1 ; 0 x x 0 2 ; 0 x x 0 3 ; 1 x x 1 4 ; 1 x x 1 5 ; 1 x x 1 6 ; 1 x x 1 7 Reading the D column from the bottom gives us our minterm %1111000 or $f0. Next example, you'll have seen this minterm often as well. Let's say you want to take your bob and OR/merge it with the screen. Let's use A for BOB, B for screen, D for final screen value, and fill in the table. We want D to be 1 if either the BOB or the screen is 1 (A OR B) Code: ; A B C D Bit Number ; 0 0 x 0 0 ; 0 0 x 0 1 ; 0 1 x 1 2 ; 0 1 x 1 3 ; 1 0 x 1 4 ; 1 0 x 1 5 ; 1 1 x 1 6 ; 1 1 x 1 7 That gives us %11111100, $fc. I bet you've seen $fc a lot You might be tempted to just do this with your multi-bitplane BOBs, but then you notice the colors go all crazy. Imagine a small diamond shape in 2 bitplanes. Let's have the left half in colour01 (1s set on bpl1) and the right half in color02 (1s set on bpl2) Code: 00012000 00112200 01112220 11112222 01112220 00112200 00012000 If you just use the A OR B minterm with this kind of image then if there is already data on the screen then when you blit your color01 on bitplane 1 then if bitplane 2 already has some data there then you are going to end up with color03 there. Not what we want at all. This assumes non-interleaved screen as it's easiest to explain first. We are blitting on 2 bitplanes, but the cookie/mask shape would be the same for both - we want an outline of the diamond shape for our mask. This is where the cookie term comes from, we are cutting out a shape. Code: 00011000 00111100 01111110 11111111 01111110 00111100 00011000 A is the mask, B is the BOB, C is the screen, D is the final screen. Basically we only "let" the BOB data influence the final screen data when the mask is 1. When the mask is 0 then we leave the screen alone. When mask is 1 and BOB is 1 then we write 1 to the screen. When mask is 1 and BOB is 0 we CLEAR the screen Code: ; A B C D Bit Number ; 0 0 0 0 0 ; 0 0 1 1 1 ; 0 1 0 0 2 ; 0 1 1 1 3 ; 1 0 0 0 4 ; 1 0 1 0 5 ; 1 1 0 1 6 ; 1 1 1 1 7 Minterm is %11001010 or $ca You do two blits, one for bpl1 and the mask, then one for bpl2 with the same mask. Does that make any sense at all, or is it worse now ? These days I use the assembler to generate the minterm like this (seems I was the last person to figure this out lol). This is my vertical fill minterm which is A XOR B. The BLTEN values are from my standard macros. There seems to be similar values in the CBM includes in hardware/blit.i Code: ;Blitter logic macros ;& (bitwise and) ;^ (bitwise exclusive-or) ;\| (bitwise inclusive-or) ;! (bitwise not) BLTEN_A = $0800 BLTEN_B = $0400 BLTEN_C = $0200 BLTEN_D = $0100 BLTEN_AD = (BLTEN_A\|BLTEN_D) BLTEN_ABD = (BLTEN_A\|BLTEN_B\|BLTEN_D) BLTEN_ACD = (BLTEN_A\|BLTEN_C\|BLTEN_D) BLTEN_ABCD = (BLTEN_A\|BLTEN_B\|BLTEN_C\|BLTEN_D) BLT_A = %11110000 BLT_B = %11001100 BLT_C = %10101010 ;Example use for A XOR B ;move.w #$0d3c,bltcon0(a6) move.w #BLTEN_ABD+(BLT_A^BLT_B),bltcon0(a6) Last edited by Antiriad_UK; 18 November 2019 at 12:19. Reason: Typos

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Blitter queues	h0ffman	Coders. General	28	22 August 2019 11:29
Blitter problem	zeGouky	Coders. Asm / Hardware	7	26 March 2014 15:12
Blitter busy flag with blitter DMA off?	NorthWay	Coders. Asm / Hardware	9	23 February 2014 22:05
Help, need a CWB refresher please!	rave	project.ClassicWB	9	03 January 2011 17:08
Blitter Question.	cdoty	Coders. General	11	06 May 2005 16:22

05 December 2014, 10:03	#1
jimmy2x2x Beyond Mutton Join Date: Mar 2011 Location: North West, UK Age: 48 Posts: 347	Quick blitter refresher please! I'm plodding away at my bruce Lee project and have been using hardware sprites exclusively up until now, the time has come to use the blitter! I haven't touched it for decades and was hoping for a quick refresher, pretty please ☺ Maybe something like a simple straight memory copy would be great, although any well documented source would be useful. Thanks!

05 December 2014, 12:17	#2
pmc gone Join Date: Apr 2007 Location: completely gone Posts: 1,596	Don't usually come here anymore but spotted this on an infrequent visit and so, for old times sake: Wait for blitter to be ready (might also be worth setting blitter priority bit first in dmacon (not shown in snippet below)): Code: .wait: btst.b #6,$dff002 bne.b .wait then set required bits of blitter control regs, masks, modulos and pointers as relevant for the blit you want to do and then write to blitsize reg ($dff058) to set the blit running. All very straightforward - check the well written docs as per the (what else...?) Hardware Ref Manual

05 December 2014, 13:23	#4
BippyM Global Moderator Join Date: Nov 2001 Location: Nottingham, UK Age: 44 Posts: 8,876	Why do you not visit pmc? (soorry for OT post)

05 December 2014, 15:27	#5
Photon Moderator Join Date: Nov 2004 Location: Eksjö / Sweden Posts: 4,781	Seemed like a good topic for Coppershade, so I added it. It should get you started. Hope you like it! > Programming the Blitter

05 December 2014, 16:55	#6
jimmy2x2x Beyond Mutton Join Date: Mar 2011 Location: North West, UK Age: 48 Posts: 347	Brilliant support, that's why I love this forum. Thanks very much guys, it would be easy to give up re-learning the Amiga on my own. I will try and get some useful blits working tonight!

06 December 2014, 00:26	#8
jimmy2x2x Beyond Mutton Join Date: Mar 2011 Location: North West, UK Age: 48 Posts: 347	Getting somewhere how, got the blitter doing some of the heavy lifting! Quick question about bobs or software sprites, do you need to store them with a separate mask or is that only of you want to display color0, and do you need to store a blank 16 pixel area (word aligned) with the sprite data? I'm working through the provided documentation, cheers

06 December 2014, 11:16	#9
Leffmann Join Date: Jul 2008 Location: Sweden Posts: 2,265	Unless the shape of your sprite is a solid rectangle, you will need to store a mask for it. You can generate the mask at startup however, if you can make use of color-keying and say that f.ex color 15 indicates transparency. Also, if you're doing interleaved blits then you will have to duplicate the mask for each bitplane. The so called "Blitter words" is a solution to a non-existing problem, and misinformation that has been kept alive in the Amiga programming community since forever. The intended way is to put the mask in source A and cut off that 16-pixel area on the right by setting the source A mask value to $FFFF 0000 and subtracting 2 from the source A and B modulos, just like in phx's code example.

06 December 2014, 18:12	#10
jimmy2x2x Beyond Mutton Join Date: Mar 2011 Location: North West, UK Age: 48 Posts: 347	Thanks, I'm getting my head around it slowly, it's been a while and the old grey matter isn't what it used to be!

18 November 2019, 00:08	#11
jotd This cat is no more Join Date: Dec 2004 Location: FRANCE Age: 48 Posts: 3,303	Interesting thread. I didn't know how to program the blitter at all one month ago and now I'm able to blit an image to a screen, with or without 0-15 shifting. Using only A src & D (of course) There are several things I have to improve, for instance, blitting only a part of the source image (clipping), I think I can manage it One thing I can't figure out how to do / how it works is: how to handle "transparency". I've searched around, and it seems to involve "minterms" or something like that but I'm not sure. In my case, I have converted png images to raw data (using the excellent amigeconv), aligning/adding 16 bits when the bobs can possibly be copied with shifting (for instance, background images don't need adding 16 bits, since they're pasted at X=0) That works well. Now, having set black as the first color (so all bits off = black) I'd like to use this color as "transparent" (else if I blit my bob on a background, the black border appears: I want this border gone, like sprite do) If I use ORing on the bitplanes independently, the colors are going to be modified. That's the main thing I don't understand. ATM if I had to do that I would: 1) blit 1 plane in XOR mode to turn off all bits from all destination bitplanes. This plane would have to be a ORed version of all source bitplanes. 2) blit all source planes in OR mode into destination This seems a bit clumsy, and doesn't use B & C sources. Is there a better way, someone can share code?

18 November 2019, 03:50	#13
Antiriad_UK Registered User Join Date: Mar 2019 Location: Birmingham, UK Posts: 142	I find it impossible to comprehend that you can fix whdload slaves that appear like witchcraft to me but don’t do blitter masks. I understand the page mcgeezer shows the HKRM but also remember that it made no sense to me at the time. And also made no sense to me recently. I’m dumb as fuck clearly. But cookie cut minterms is what you need :£ I’ve always liked the blitter truth table way of working where you draw up the A and B and C diagram and work out how to merge them together into a D. So even if you don’t understand what you are doing you can get the result you want. But in this case you need to come up with a “mask” or new solid shape that lets you say where is solid and where is transparent. If you have a raw image and you try and blit that to a screen. Yep you are going to obliterate the existing picture. But if you just OR it to the screen (A OR B = D) you will also mess it up because you will create new colours. The cookie cut thing is where you have to create a whole new single bpl “shape” that you apply to all operations. Usually it will be a solid shape that only has holes (00s) where you want transparency. Most of the iff to raw software (like piccon) will create a raw image that has this mask per bpl automatically. It really needs a diagram. Someone somewhere must have done it?!! The you use a minterm that says something like D equals A (bob data) OR B (existing screen data) AND C (a mask). So if the mask is 1 ( the big solid outline of the shape) then you pass through the A/bob data. If the mask is 0 then you ignore the Bob data and just use the existing B(current screen) data ( transparency) The thing to understand is that you need a generated mask to make this work. Just converting an image to raw doesn’t get you that. The conversion also has to look at all the bitplanes and then generate an appropriate mask set of bitplanes. Your conversion software of choice will usually mention masks - this is what they mean. I was exceptionally drunk when I wrote this and just read it back and it made no sense. But i think when I can form a blitter truth table in the morning or when mcgeezer explains it properly we will get there (I also may have reversed B and C for the usual $fca = cookie cut minterm)

18 November 2019, 10:12	#14
DanScott Lemon. / Core Design Join Date: Mar 2016 Location: Sunny Bournemouth, UK Posts: 480	A and B will be your source bob & mask (as those are the 2 channels that you can shift)

18 November 2019, 10:18	#15
mcgeezer Registered User Join Date: Oct 2017 Location: Sunderland, England Posts: 1,510	As i need to explain this in my game dev series anyway i’ll try and do some power point slides tonight that make it all clear.

18 November 2019, 11:29	#16
jotd This cat is no more Join Date: Dec 2004 Location: FRANCE Age: 48 Posts: 3,303	@Antiriad_UK yeah, incredible right? I've fixed blitter issues where I saw blitter writes and all, I've fixed a lot of CPU issues, copperlist issues, display, etc... but never really tried to understand the details of the blitter (or playfields, or sprites). Don't worry I'm a quick learner once I put my mind to it and with help of this wonderful forum! thanks for all this. $9F0 rings a bell (the value I'm currently using) and I'll try cookie cut after having masked source planes together to use as B source. I think I'll manage. when you read blitter "tutorials" they explain you all the minterm equation shit and you don't understand anything practical. Okay I can mask/shift and test XOR/AND at the same time on 3 different planets but I just wanted to paste an image...

18 November 2019, 22:36	#18
jotd This cat is no more Join Date: Dec 2004 Location: FRANCE Age: 48 Posts: 3,303	that makes a lot of sense. I'm using amigeconv which does NOT create the extra mask "bitplane" but I'm also hacking the converted "raw" format to add dimensions, number of planes (header), so I can also read bitplane data, OR them together and add the last bitplane, or just generate it when I read the data (which is less flexible as if we need a real black and not transparent we can't do that) Thanks. I'll test that when I have the time. Too much work/family/sports/other ATM...

18 November 2019, 22:44	#19
BippyM Global Moderator Join Date: Nov 2001 Location: Nottingham, UK Age: 44 Posts: 8,876	What's abcd?

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)