Old style PLANEPTR masks alignment probs

I'm trying to create a bitplane mask to use with BitMaskBitMapRastPort (or, in actual fact, the BltBitMapTags equivalent) for arbitrary BitMaps.

I've created the mask with AllocRaster(width, height) and poked the mask in by referencing it as an array.

This works for some bitmaps, but not for others - and I think the problem is because the bitplanes are 16-bit(?) aligned, and when I'm poking the values in I'm not taking any extra space into account.

Basically my routine is:


Basically I think when the width is not a multiple of 8, width/8 gets rounded down and that causes a problem, but also when the width itself isn't a multiple of 16, that also causes a problem because I'm not skipping the extra bits at the end of the plane.

Any ideas how to work around this?

(as an aside - picture.datatype documentation is misleading, as it suggests that PDTA_MaskPlane will return a 1-bit mask, with no mention that it doesn't if the mask type is mskHasAlpha)

You mask plane should be

bitmap->Rows * Bitmap->BytesPerRow / 8

in size.

BytesPerRows is not always the same as width/8

The bitmap allocated for a given sized image is likely to be slighty larger.

You should probably use GetBitmapAttr() to get the info rather than direct use the values in the structure.

If that doesn't help then I need to see more details of the code creates the bitmap you are masking ...


[edit] fotget to divide by 8[/edit]

@Chris

You're code should be:

Don't try to calculate pbr let the OS give you the correct values.

Some thing might change or it might not be the same on different graphic card drivers.

@LiveForIt

Quote:

AllocRaster() will always pad to 16 pixels and only 16 pixels. This was not changed for OS3.0/AGA (instead AllocBitMap() was introduced) and I doubt it will ever change because it's definition does not allow it.

If you think the calculation is too complex there is always the RASSIZE macro in graphics/gfx.h that can be used:
int bpr = RASSIZE(width, 1);

Also using the bytesperrow of a chunky bitmap (width * bytesperpixel) to allocate a 1-bitplane planar mask certainly does not make any sense.

Quote:

It may do but it's still more correct to get the size from the bitmap. That may be aligned differently. (pershaps 32bit? not definetely just perhaps, you don;t know so don;t assume)


Quote:

oops forgot to divide by 8.... well spotted.

@broadblues

Quote:

Quote:

A simple GetBitMapAttr(bitmap, BMA_WIDTH) will get the width including padding from the bitmap that can then be used in AllocRaster() and then RASSIZE() to calculate the bpr of the mask. No need to have a hardcoded divide by 8 that will fail with high- and true-colour bitmaps.

@broadblues

Using BMA_WIDTH rather than calculating the width from BytesPerRow is also more future proof because in AmigaOS >= 3.0 the BytesPerRow is defined only as the value that needs to be added to the raster pointer to get from an x position in one row to the same x position in the next (y+1) row (depending on the format of the bitmap like if it's interleaved f.e. or allocated upside down with a negative BPR it might not be so simple to calculate the pixel width from it).

That is confusing.

So number of BytesPerRow really is BytesPerRow * NumberOfBitPlanes

@LiveForIt

Quote:

Only if it's an interleaved planar bitmap (the concept of interleaved bitmaps was introduced in AmigaOS 3.0). For the reasoning behind the new definition of BytesPerRow you should see the V39_AA_Compatibility document from NDK 3.1 where it is explained in some detail.

There's a trick to calculate BytesPerRow if PixelsPerRow is given. Here are appropriate equations:

BytesPerRow = (PixelsPerRow + 7) >> 3;

So you add 7 then divide by 8. This way the nearest ceiling BPR value is given (taken from: ceiling of a real number is the nearest integer number not smaller than this number).

This way the WordsPerRow can be calculated as well:

WordsPerRow = (PixelsPerRow + 15) >> 4;

This can be used for example Blitter operations, because Blitter works on 16-bit words.

Thanks everyone, I think I got it working (aside from some odd corruption on the right-hand size of the masked BitMaps)

My head hurts.

@Chris

I don't think AllocRaster() clears the allocated memory so you may want to do that first with SetMem() or memset(). Also your loops don't work correctly if width isn't a multiple of 8.

Fixed version:

@Sallasso

You're completely right when you say about using BITMAP_Width

That's why I mentioned GetBitMapAttr in my first reply.

I was completely stupid to say divide by 8 I must have been half asleep.

@salass00

Oh, yeah. Thanks. Now working "as advertised"