Cookie-cut blit into an interleaved Intuition screen

[thyslo]

I’m playing around with QSBlit() to learn something about the blitter.

I’ve opened an interleaved Intuition screen 320x200 of depth=4. Then did a ‘normal’ blit with minterm $9f0 which worked fine. For a start I just blit the bob into the top left edge of the display.

Now I wanted to do a cookie cut blit of the same bob image. I created a mask for the image, duplicated it 4 times behind one another (As it is a blit to an interleaved screen with depth = 4).

But the blit result is not a I excpected. The colors don’t fit and the blit image is somehow distorted, see the attached picture.

Then, for a test, I set all mask bytes to 0. I expected that no pixel of the bob would be painted. But to my surprise, one color/pen of the image still has been blit.

My blitter setup code looks like this:

  custom.bltcon0 = 0xfca;
  custom.bltcon1 = 0;

  custom.bltamod = 0;
  custom.bltbmod = 0;
  custom.bltcmod = (displayWidthBytes - bobWidthBytes);
  custom.bltdmod = (displayWidthBytes - bobWidthBytes);
  
  custom.bltafwm = 0xffff;
  custom.bltalwm = 0xffff;

  custom.bltapt = pBobPlaneStart;
  custom.bltbpt = pMaskPlaneStart;
  custom.bltcpt = pDisplayPlaneStart;
  custom.bltdpt = pDisplayPlaneStart;

  custom.bltsize = (bobHeight * bobDepth) * 64) + bobWordWidth;

Is there something obvious I'm doing wrong?

[roondar]

In cookie-cut blits with minterm $FCA, the mask goes into source A and the image to blit goes into source B. You could make a minterm where it's reversed so that the mask goes in B and the image in A, but this is probably the issue you're having here.

[a/b]

Yup, either swap A and B, or use function AB+C!B=$c0+$22=$e2.

[DanScott]

Originally Posted by roondar

In cookie-cut blits with minterm $FCA, the mask goes into source A and the image to blit goes into source B. You could make a minterm where it's reversed so that the mask goes in B and the image in A, but this is probably the issue you're having here.

This 100%

I was talking on Facebook yesterday, saying how it's instinctive to put the source image in A, but with cookie cut, the mask goes there, as the FWM and LWM will mask out any garbage when shifting (ie. the source image in B does not need an extra word of empty data to shift into)

[thyslo]

Thanks for all your help! Swapping the mask image pointer and the bob image pointer solved it

[thyslo]

So, another week, another blitter related problem.

I now can move a bob with QSBlit() on an interleaved Intuition screen. It works great when the screen is in 320x256 resolution.

But when I open the screen smaller, e.g., in 256 x 256, there are distortions visible ( [ Show youtube player ]). They seem to come from the A->D background restauration blit, not from the cookie-cut blit which draws the bob itself.

When the bob is moved the background is restored from a read only copy of background image using this A->D blit:

  custom.bltcon0 = 0x9f0;
  custom.bltcon1 = 0;

  custom.bltafwm = 0xffff;
  custom.bltalwm = 0xffff;

  custom.bltamod = (displayWidthBytes - bobWidthBytes);   // Modulo for src (BOB)
  custom.bltdmod = (displayWidthBytes - bobWidthBytes);   // Modulo for destination D (Background)

  // pBackgroundPlaneStart - read only copy of background image
  custom.bltapt = pOrigBackgndPlane
                + (displayWidthBytes * y * bobDepth)
                + ((x & 0xfff0) / 8);

  custom.bltdpt = pDisplayPlane
                + (displayWidthBytes * y * bobDepth)
                + ((x & 0xfff0) / 8);

  custom.bltsize = bltSize;

The bob image itself is drawn with this cookie-cut blit:

  custom.bltcon0 = 0xfca | ((x & 0xf) << 12);
  custom.bltcon1 = (x & 0xf) << 12;

  custom.bltamod = -2;
  custom.bltbmod = -2;
  custom.bltcmod = (displayWidthBytes - bobWidthBytes);
  custom.bltdmod = (displayWidthBytes - bobWidthBytes);

  custom.bltafwm = 0xffff;
  custom.bltalwm = 0x0;

  custom.bltapt = pBobMaskData;
  custom.bltbpt = pBobImageData;

  custom.bltcpt = pDisplayPlane
                + ((displayWidthBytes * y * bobDepth))
                + ((x & 0xfff0) / 8);

  custom.bltdpt = pDisplayPlane
                + ((displayWidthBytes * y * bobDepth))
                + ((x & 0xfff0) / 8);

  custom.bltsize = bltSize;

For both blits the bobWidthBytes is initialized 2 Bytes bigger than the actual bob width for shifting, although shifting isn’t used in the A->D blit.

I wonder what the reason for the distortion could be and why it seemingly works great on a 320x256 resolution screen.

[a/b]

Is the background image you are blitting from also 256x256, or still 320x256?
If it's the latter, you're initializing A mod/ptr with incorrect values.

[thyslo]

The background image is also 256x256.

But on screen opening center the screen on the display by adjusting its top left coordinates:

//
// Initialize screen properties, then open screen and window
//
screenLeft = (320 - bgWidth) / 2;
screenTop = (256 - bgHeight) / 2;

pScreen = OpenScreenTags(NULL,
                   SA_DisplayID, PAL_MONITOR_ID|LORES_KEY,
                   SA_Left, screenLeft,
                   SA_Top, screenTop,
                   SA_Width, bgWidth,
                   SA_Height, bgHeight,
                   SA_Depth, bgDepth,
                   SA_ShowTitle, FALSE,
                   SA_Interleaved, TRUE,
                   SA_Quiet, TRUE,
                   SA_Type, CUSTOMSCREEN,
                   SA_Exclusive, TRUE,
                   SA_Colors32, (ULONG)pBackground->pColors32,
                   TAG_DONE);




// ...

// Blit the background picture on the screen
BltBitMapRastPort(pBackground->pBitMap,
            0,
            0,
            &pScreen->RastPort,
            0,
            0,
            bgWidth,
            bgHeight,
            0xC0);

But I guess, it should not be a problem, because I blit into the screens BitMap.

[a/b]

It looks to me that your screen is still 320x256 (32x256 on the left, 256x256 visible central part, 32x256 on the right), while the background is 256x256.
displayWidthBytes is 320/8=40?

edit: or 288x256 (without the right 32x256 part).

[thyslo]

Sorry I had a typo in my posts above: The screen is actually opened in 224 x 256 resolution. As this is also the size of the background image. And the actual values after OpenScreen are:

// Values from debugger:
// pScreen->Width: 224
// pScreen->Height: 256

// ...

displayWidthBytes = GetBitMapAttr(pScreen->RastPort.BitMap, BMA_WIDTH) / 8;

// Value from debugger:
// displayWidthBytes: 32

I think, displayWidthBytes is wrong here. It should be 28 for a 224 screen width.

So, OpenScreen() seems to create a BitMap 256 pixels wide instead of 224.

Maybe I should use a defualt 320x256 background image instead.