Calculations for a simple blit?

[deimos]

I'm having trouble figuring out all the values I need for this, and maybe it will be less frustrating to just ask than to try and work it all out myself.

For context, this is for the direction indicator on the flight sim game I'm attempting.

I have an image, 128x7 px (3 interleaved bitplanes), this has the compass points for my direction indicator:

[ . N . E . S . W . N . ]

I'm trying to grab a 37 px wide segment of that, starting at an x position I've already calculated, and blit it to a fixed point (266, 50) on my instrument panel (also 3 interleaved bitplanes).

I'm coming unstuck trying to understand the shifting and masking and first and last words. I've read the "Copying Arbitrary Regions" page in the HRM, but I'm not getting it all.

Can anyone help?

static void BlitterCopy(WORD start) {
    WORD offset = (start >> 3) & 0xfffe;
    WORD shift = start & 0x000f;

    KPrintF("start = %ld, offset = %ld, shift = %ld.\n", start, offset, shift);

    WaitForBlitter();

    custom->bltcon0 = (SRCB | SRCC | DEST) | (ABC | ABNC | NABC | NANBC);

    custom->bltcon1 = (shift << BSHIFTSHIFT);

    custom->bltafwm = 0x001f;
    custom->bltalwm = 0xffff;

    custom->bltadat = 0xffff;
    custom->bltbpt = headingIndicator + offset;
    custom->bltcpt =
    custom->bltdpt = display.displayBuffers[display.back].instrumentsBuffer +
                         50 * INSTRUMENTS_DISPLAY_DEPTH * DISPLAY_WIDTH_IN_BYTES +
                         32; // 32 = (266 >> 3) & 0xfffe

    custom->bltamod =
    custom->bltbmod = 10;
    custom->bltcmod =
    custom->bltdmod = DISPLAY_WIDTH_IN_BYTES - WIDTH_IN_BYTES;

    custom->bltsize = INSTRUMENTS_DISPLAY_DEPTH * HEIGHT << 6 | WIDTH_IN_WORDS;
}

Edit: The current situation is that I appear to be blitting into the correct destination area, without writing over any bits I shouldn't, but the bits I'm writing are not correct - it is not picking up the bits of the source that I'm expecting.

The attached screenshot is for values:

start = 48, offset = 6, shift = 0.

(from the KPrintF). It's gone off the edge of the source. I don't see why.

[roondar]

Ok, perhaps this helps:

Masking is just picking which pixels the Blitter ignores. Every bit in the first word mask (BLTAFWM) corresponds to a single pixel of the source image (or mask, but that achieves the same result). These are ordered left to right, so bit 15 is the first pixel of the source/mask, bit 14 the second, etc. In this mask, setting a bit to 1 means the pixels needs to be included into the blit, setting it to 0 means it should be excluded.

For the last word mask (BLTALWM), the same goes but rather than applying to the leftmost word of the source/mask, it applies to the rightmost word of the source/mask.

As an example: suppose your source image is stored from pixels 13-50. This would mean using the Blitter to grab pixels 0-63. The mask then needs to be set up to ignore pixels 0-12 and 51-63. This would mean setting the BLTAFWM to 0 for bits 15-4 and to 1 for bits 3-0. The last word mask meanwhile needs to be set to 1 for bits 15-13 and to 0 for bits 12-0.

Note here that the masks only apply to the non-shifted source (or mask). Shifting is done separately from masking. Shifts only apply to what the Blitter outputs.

To shift, the Blitter usually needs to blit one extra word (where any shifted pixels go) and it needs a shift value for both the mask and the source image. This value is just the number of pixels the image needs to be moved to the right from the nearest multiple of 16 pixels to be in the correct position.

So, blitting to X=0 means a shift value for A&B channels of 0. Blitting to X=1 means a value of 1, etc. Similarly, blitting to X=28 would mean a shift value of 12 (nearest multiple of 16=16. 28-16=12).

Note you can use a bitwise AND to quickly get the number of pixels that need to be shifted.

Edit: there is an important caveat I forgot to mention.
While the Blitter indeed shifts only after masking, you do have keep in mind that blitting an extra word in the output also blits an extra word from the input. This probably affects the required values for masking.

[deimos]

Originally Posted by roondar

Ok, perhaps this helps:

Masking is just picking which pixels the Blitter ignores. Every bit in the first word mask (BLTAFWM) corresponds to a single pixel of the source image (or mask, but that achieves the same result). These are ordered left to right, so bit 15 is the first pixel of the source/mask, bit 14 the second, etc. In this mask, setting a bit to 1 means the pixels needs to be included into the blit, setting it to 0 means it should be excluded.

For the last word mask (BLTALWM), the same goes but rather than applying to the leftmost word of the source/mask, it applies to the rightmost word of the source/mask.

As an example: suppose your source image is stored from pixels 13-50. This would mean using the Blitter to grab pixels 0-63. The mask then needs to be set up to ignore pixels 0-12 and 51-63. This would mean setting the BLTAFWM to 0 for bits 15-4 and to 1 for bits 3-0. The last word mask meanwhile needs to be set to 1 for bits 15-13 and to 0 for bits 12-0.

Note here that the masks only apply to the non-shifted source (or mask). Shifting is done separately from masking. Shifts only apply to what the Blitter outputs.

To shift, the Blitter usually needs to blit one extra word (where any shifted pixels go) and it needs a shift value for both the mask and the source image. This value is just the number of pixels the image needs to be moved to the right from the nearest multiple of 16 pixels to be in the correct position.

So, blitting to X=0 means a shift value for A&B channels of 0. Blitting to X=1 means a value of 1, etc. Similarly, blitting to X=28 would mean a shift value of 12 (nearest multiple of 16=16. 28-16=12).

Note you can use a bitwise AND to quickly get the number of pixels that need to be shifted.

Edit: there is an important caveat I forgot to mention.
While the Blitter indeed shifts only after masking, you do have keep in mind that blitting an extra word in the output also blits an extra word from the input. This probably affects the required values for masking.

Ok. It sounds like I should first tackle the shifting and make sure that I can get an unmasked blit happening correctly, but with extra pixels, then come back to the masks to remove the unwanted pixels.

Back in a bit.

[DanScott]

Remember also, the blitting a masked area from one arbitrary x position, to another, may require a subtraction of 2 from the destination address (essentially you are "scrolling" the source image left)

and also if your destination is not word aligned, will require being "or'd" in rather than a straight D=A copy

[deimos]

Originally Posted by DanScott

Remember also, the blitting a masked area from one arbitrary x position, to another, may require a subtraction of 2 from the destination address (essentially you are "scrolling" the source image left)

and also if your destination is not word aligned, will require being "or'd" in rather than a straight D=A copy

I did not expect it to be this hard.

[a/b]

Not going to tell you how to design stuff, but I have to say you are... too artistic :P.
266? 37? What's wrong with nicely rounded sizes and coords, multiples of 16. Makes life much easier.

Now, about how you shift B (heading image)... If the offset if say 1 and you have to skip the first pixel, you have to shift towards the left. And since you are blitting top-to-bottom/left-to-right, blitter shifts towards the right, you actually have to shift B by 16-1 and adjust pointer. And additionally, since your D pixel is not word-aligned, it starts at bit 266&$000f = 10 (256+10), you have to shift B into position 10. So even if the offset is 0, you still have to shift B by 10 towards the right.
This is all easier with say x=272, and width=32 (maybe too narrow) wouldn't hurt either but it's just extra masking if it's not.

[deimos]

Originally Posted by a/b

Not going to tell you how to design stuff, but I have to say you are... too artistic :P.
266? 37? What's wrong with nicely rounded sizes and coords, multiples of 16. Makes life much easier.

Now, about how you shift B (heading image)... If the offset if say 1 and you have to skip the first pixel, you have to shift towards the left. And since you are blitting top-to-bottom/left-to-right, blitter shifts towards the right, you actually have to shift B by 16-1 and adjust pointer. And additionally, since your D pixel is not word-aligned, it starts at bit 266&$000f = 10 (256+10), you have to shift B into position 10. So even if the offset is 0, you still have to shift B by 10 towards the right.
This is all easier with say x=272, and width=32 (maybe too narrow) wouldn't hurt either but it's just extra masking if it's not.

Well, sure, but I was under the impression that the blitter made it easy, and I managed to blit the artificial horizon, which included a mask to make it circular, with no problem at all. It's just the fact that this is blitting a non-fixed source that's doing my head in.

If I can get the first step of blitting with shifting without masking to work correctly I'll be back, but at the moment that just seems to be randomly broken.

[roondar]

Originally Posted by deimos

Well, sure, but I was under the impression that the blitter made it easy

Ahh, yes.. I made that mistake too when I started looking into the Blitter (and trust me, there was plenty of frustration in the initial stages). Thing is, the Blitter is designed to make things faster, not easier

When using the Blitter, it makes your life a lot easier if the source images are aligned to 16 pixel boundaries because the Blitter only ever operates on data a word at a time (which corresponds to 16 pixels in memory). Like a/b said, it's not for me to tell you how to design your source images. But still, it's worth a thought.

[deimos]

Originally Posted by roondar

Ahh, yes.. I made that mistake too when I started looking into the Blitter (and trust me, there was plenty of frustration in the initial stages). Thing is, the Blitter is designed to make things faster, not easier

When using the Blitter, it makes your life a lot easier if the source images are aligned to 16 pixel boundaries because the Blitter only ever operates on data a word at a time (which corresponds to 16 pixels in memory). Like a/b said, it's not for me to tell you how to design your source images. But still, it's worth a thought.

I could rotate my source image to simplify the situation, I suppose?

[roondar]

Originally Posted by deimos

I could rotate my source image to simplify the situation, I suppose?

Yes, normally it will as then each line should be 16-bit (pixel) aligned*. Which makes blitting easier.

*) Assuming it's stored in memory in a sane, Amiga friendly way - which is normally the case.

[deimos]

Originally Posted by roondar

Yes, normally it will as then each line should be 16-bit (pixel) aligned*. Which makes blitting easier.

*) Assuming it's stored in memory in a sane, Amiga friendly way - which is normally the case.

This is my new source image - no dependency on how it aligns, later I'll redraw it to match what the blitter wants.

Right now all I expect is to be able to take parts of it to blit to my fixed destination. But, that's not working at all, as if my shift and offsets aren't calculated correctly, but I can't see how that could be incorrect:

    WORD offset = ((start >> 3) & 0xfffe);
    WORD shift = start & 0x000f;

    // ...

    custom->bltcon1 = (shift << BSHIFTSHIFT);

    // ...

    custom->bltbpt = headingIndicator + offset;

Edit:

For example, when start = 87, I get offset = 10 and shift = 7, which looks sensible to me, but what gets blit looks corrupted, as if it's gone round the edge of the bitmap?

[deimos]

Originally Posted by deimos

Edit:

For example, when start = 87, I get offset = 10 and shift = 7, which looks sensible to me, but what gets blit looks corrupted, as if it's gone round the edge of the bitmap?

Ok, so there should probably be some sort of licensing scheme for pointer arithmetic.

My shifting is still not right though, working on that.

[deimos]

Originally Posted by deimos

My shifting is still not right though, working on that.

My shifting is the opposite of what I expected:

    WORD shift = 15 - (start & 0x000f);

Which means that stuff is wrapping round on the left now, but I'm getting closer.

[deimos]

Originally Posted by a/b

since you are blitting top-to-bottom/left-to-right, blitter shifts towards the right, you actually have to shift B by 16-1 and adjust pointer.

I think this is where I am at the moment. Things seems to work, except for shift values of 12 to 15 I get wrapped around garbage values appearing at the left.

static void BlitterCopy(WORD start) {
    WORD offset = ((start >> 3) & 0xfffe);
    WORD shift = 15 - (start & 0x000f);

    KPrintF("start = %ld, offset = %ld, shift = %ld.\n", start, offset, shift);

    WaitForBlitter();

    custom->bltcon0 = (SRCB | SRCC | DEST) | (ABC | ABNC | NABC | NANBC);

    custom->bltcon1 = (shift << BSHIFTSHIFT);

    custom->bltafwm = 0x001f;
    custom->bltalwm = 0x0000;

    custom->bltadat = 0xffff;
    custom->bltbpt = (APTR) headingIndicator + offset;
    custom->bltcpt =
    custom->bltdpt = display.displayBuffers[display.back].instrumentsBuffer +
                         50 * INSTRUMENTS_DISPLAY_DEPTH * DISPLAY_WIDTH_IN_BYTES +
                         32;

    custom->bltamod =
    custom->bltbmod = 8;
    custom->bltcmod =
    custom->bltdmod = DISPLAY_WIDTH_IN_BYTES - WIDTH_IN_BYTES;

    custom->bltsize = INSTRUMENTS_DISPLAY_DEPTH * HEIGHT << 6 | WIDTH_IN_WORDS;
}

So, like has been mentioned a couple of times in this thread, I need to blit a word wider? That's fine, but how do I get rid of that extra word? Is this the "subtraction of 2 from the destination address" that DanScott referred to? Do I need to treat this as a special case for just those shift values?

[roondar]

About adding a word for shifting. I find it helps to consider the Blitter as if it's working on a stream of memory, rather than a rectangular block of memory. Whenever the Blitter reaches the rightmost word of the block it is blitting, it adds the modulo and continues blitting as if there is no gap in memory. If it's shifting, it does a bitwise shift once every time it should blit on a new line.

Kind of like this:

Some part of the screen
<some stuff on the left>.xx.xx.<some stuff on the right>
<some stuff on the left>x..x..x<some stuff on the right>
<some stuff on the left>...xxx.<some stuff on the right>
<some stuff on the left>xx..x.x<some stuff on the right>
Same, as stored in memory
<some bytes>.xx.xx.<some bytes>x..x..x<some bytes>...xxx.<some bytes>xx..x.x<some bytes>
Same, as seen by the Blitter after modulos are applied
<some bytes>.xx.xx.x..x..x...xxx.xx..x.x<some bytes>
Same, after three pixel shift by Blitter
<some bytes>....xx.xx....x..x..x......xx<some bytes>

So, when the Blitter shifts, it is doing a bitwise shift along this stream. It stays inside of the limits of the total area (that is, it won't write past the last word it's supposed to), but essentially doesn't care about edges when shifting. When you shift by three pixels, basically the stream is shifted by three bits to the right once per the amount of words the Blit is wide.

Now, doing this will obviously create corruption without some additional measures. This is where the extra word comes in. By adding an extra word to blit for both source and destination, there is some 'space' to shift in the extra bits we end up with. If this word is kept empty in the source, the extra pixels can fit there without corruption showing up.

So let's repeat this, but now with the extra word for shifting

Some part of the screen
<some stuff on the left>.xx.xx.****<some stuff on the right>
<some stuff on the left>x..x..x****<some stuff on the right>
<some stuff on the left>...xxx.****<some stuff on the right>
<some stuff on the left>xx..x.x****<some stuff on the right>
Same, as stored in memory
<some bytes>.xx.xx.****<some bytes>x..x..x****<some bytes>...xxx.****<some bytes>xx..x.x****<some bytes>
Same, as seen by the Blitter after modulos are applied
<some bytes>.xx.xx.****x..x..x****...xxx.****xx..x.x****<some bytes>
Same, after three pixel shift by Blitter
<some bytes>....xx.xx.*...x..x..x*......xxx.*...xx..x.x*<some bytes>

The * represent the extra word blit

Note that this does mean using more memory for graphics (one extra word per line per bitplane for all objects that need to be blit).

This can however be solved by using the Blitter's last word mask (BLTALWM) feature and changing the source modulo's. Without getting into the details (this post is long enough as it is), you change the source modulo from 0 to -2 and change the last word mask from #$ffff to #$0000. This way you'll still need to blit the extra word per line, but no longer need to store empty space in memory for it.

Edit: just to be clear, my diagrams are not full words per line. Just pretend they are

[deimos]

Originally Posted by roondar

About adding a word for shifting. I find it helps to consider the Blitter as if it's working on a stream of memory, rather than a rectangular block of memory. Whenever the Blitter reaches the rightmost word of the block it is blitting, it adds the modulo and continues blitting as if there is no gap in memory. If it's shifting, it does a bitwise shift once every time it should blit on a new line.

Kind of like this:

Some part of the screen
<some stuff on the left>.xx.xx.<some stuff on the right>
<some stuff on the left>x..x..x<some stuff on the right>
<some stuff on the left>...xxx.<some stuff on the right>
<some stuff on the left>xx..x.x<some stuff on the right>
Same, as stored in memory
<some bytes>.xx.xx.<some bytes>x..x..x<some bytes>...xxx.<some bytes>xx..x.x<some bytes>
Same, as seen by the Blitter after modulos are applied
<some bytes>.xx.xx.x..x..x...xxx.xx..x.x<some bytes>
Same, after three pixel shift by Blitter
<some bytes>....xx.xx....x..x..x......xx<some bytes>

So, when the Blitter shifts, it is doing a bitwise shift along this stream. It stays inside of the limits of the total area (that is, it won't write past the last word it's supposed to), but essentially doesn't care about edges when shifting. When you shift by three pixels, basically the stream is shifted by three bits to the right once per the amount of words the Blit is wide.

Now, doing this will obviously create corruption without some additional measures. This is where the extra word comes in. By adding an extra word to blit for both source and destination, there is some 'space' to shift in the extra bits we end up with. If this word is kept empty in the source, the extra pixels can fit there without corruption showing up.

So let's repeat this, but now with the extra word for shifting

Some part of the screen
<some stuff on the left>.xx.xx.****<some stuff on the right>
<some stuff on the left>x..x..x****<some stuff on the right>
<some stuff on the left>...xxx.****<some stuff on the right>
<some stuff on the left>xx..x.x****<some stuff on the right>
Same, as stored in memory
<some bytes>.xx.xx.****<some bytes>x..x..x****<some bytes>...xxx.****<some bytes>xx..x.x****<some bytes>
Same, as seen by the Blitter after modulos are applied
<some bytes>.xx.xx.****x..x..x****...xxx.****xx..x.x****<some bytes>
Same, after three pixel shift by Blitter
<some bytes>....xx.xx.*...x..x..x*......xxx.*...xx..x.x*<some bytes>

The * represent the extra word blit

Note that this does mean using more memory for graphics (one extra word per line per bitplane for all objects that need to be blit).

This can however be solved by using the Blitter's last word mask (BLTALWM) feature and changing the source modulo's. Without getting into the details (this post is long enough as it is), you change the source modulo from 0 to -2 and change the last word mask from #$ffff to #$0000. This way you'll still need to blit the extra word per line, but no longer need to store empty space in memory for it.

Edit: just to be clear, my diagrams are not full words per line. Just pretend they are

That is very comprehensive, thank you.

I'm extracting a variable part of my source image strip [ N E S W] - if I'm facing north I'll extract essentially the left quarter [ N ], if I'm facing south I'll take the middle quarter [ S ].

From your first reply to this thread, I believe I should set up the first and last word masks according to what I want to extract, regardless of how it's going to be shifted in the output. I'm not currently doing this.

I should set my blit size to be bigger by one word to allow for the shifts (and adjust the modulo to match). I should widen my image to make sure there are bits to shift, but I already repeat part of the image to allow for wrap-around, so maths might mean it's not needed, I'll check.

I guess I need a separate mask and shifting to get things into the right spot on the output without overwriting stuff. But then these shifts need to be coordinated with the shifts needed to extract the source?

[deimos]

Originally Posted by deimos

That is very comprehensive, thank you.

I'm extracting a variable part of my source image strip [ N E S W] - if I'm facing north I'll extract essentially the left quarter [ N ], if I'm facing south I'll take the middle quarter [ S ].

From your first reply to this thread, I believe I should set up the first and last word masks according to what I want to extract, regardless of how it's going to be shifted in the output. I'm not currently doing this.

I should set my blit size to be bigger by one word to allow for the shifts (and adjust the modulo to match). I should widen my image to make sure there are bits to shift, but I already repeat part of the image to allow for wrap-around, so maths might mean it's not needed, I'll check.

I guess I need a separate mask and shifting to get things into the right spot on the output without overwriting stuff. But then these shifts need to be coordinated with the shifts needed to extract the source?

Maybe one problem is that I'm trying to be too specific. Maybe I should go and write a generic (rectangular, non-overlapping) blit function first, then use that as a basis for specific versions like this.

[deimos]

Got it!

Thank you everyone.

Edit:

For those playing along at home, this is the working version I've come up with:

const WORD fwms [16] = { 0xffff, 0x7fff, 0x3fff, 0x1fff, 0x0fff, 0x07ff, 0x03ff, 0x01ff, 0x00ff, 0x007f, 0x003f, 0x001f, 0x000f, 0x0007, 0x0003, 0x0001 };
const WORD lwms [16] = { 0x8000, 0xc000, 0xe000, 0xf000, 0xf800, 0xfc00, 0xfe00, 0xff00, 0xff80, 0xffc0, 0xffe0, 0xfff0, 0xfff8, 0xfffc, 0xfffe, 0xffff };

static void BlitterCopy(const WORD startX) {
    const WORD sourceShift = startX & 0x000f;
    const WORD destinationShift = (11 + (16 - sourceShift)) & 0x000f;
    const WORD byteOffset = (startX >> 3) & 0xfffe;
    
    WaitForBlitter();

    custom->bltcon0 = (destinationShift << ASHIFTSHIFT) | (SRCB | SRCC | DEST) | (ABC | ABNC | NABC | NANBC);
    custom->bltcon1 = destinationShift << BSHIFTSHIFT;

    custom->bltafwm = fwms[sourceShift];
    custom->bltalwm = lwms[(sourceShift + 4) & 0x000f];

    custom->bltadat = 0xffff;
    custom->bltbpt = (APTR) headingIndicator + byteOffset;
    
    if (sourceShift <= 11) {
        custom->bltcpt =
        custom->bltdpt = display.displayBuffers[display.back].instrumentsBuffer +
                            50 * INSTRUMENTS_DISPLAY_DEPTH * DISPLAY_WIDTH_IN_BYTES +
                            32;

        custom->bltamod =
        custom->bltbmod = SOURCE_WIDTH_IN_BYTES - WIDTH_IN_BYTES;
        custom->bltcmod =
        custom->bltdmod = DISPLAY_WIDTH_IN_BYTES - WIDTH_IN_BYTES;

        custom->bltsize = (INSTRUMENTS_DISPLAY_DEPTH * HEIGHT << 6) | WIDTH_IN_WORDS;
    } else {
        custom->bltcpt =
        custom->bltdpt = display.displayBuffers[display.back].instrumentsBuffer +
                            50 * INSTRUMENTS_DISPLAY_DEPTH * DISPLAY_WIDTH_IN_BYTES +
                            32 - 2;

        custom->bltamod =
        custom->bltbmod = SOURCE_WIDTH_IN_BYTES - (WIDTH_IN_BYTES + 2);
        custom->bltcmod =
        custom->bltdmod = DISPLAY_WIDTH_IN_BYTES - (WIDTH_IN_BYTES + 2);

        custom->bltsize = (INSTRUMENTS_DISPLAY_DEPTH * HEIGHT << 6) | (WIDTH_IN_WORDS + 1);
    }
}

[roondar]

Originally Posted by deimos

Got it!

Thank you everyone.

Looking forward to the end result already

[deimos]

Originally Posted by roondar

Looking forward to the end result already

This week I hope to actually have the planes moving around rather than just spinning round on fixed positions.

But before I build a physics model I want a visual representation of the throttle position on the screen. Every attempt I've made to draw something has ended up looking like the slider on a 1980s Amstrad stereo.

I want to do this once, as it's a pain to lay out the pixels for every change, and I seem to have hit the limits of my pixel art skills.

Edit: I've just spent all afternoon trying to draw something, and searching for examples to copy, I think I might just have to give up. I'd hire a pixel artist, but I think my requirements will be too hard to work with someone else with.