Color 0 transparent blit
10 messages in this thread
I've been going nuts today trying to do what I thought was a simple graphics
operation but which just doesn't seem to want to work. Basically, given a
source with some pixels set to Color 0 (the background color), I want to be
able to copy all the pixels which are NOT that color over top of another image.
Like So:
Where '#' is source imagery, '+' is dest imagery, and '-' is Color 0 pixels:
Source Original Dest Result
—-#—- +++++++++ ++++#++++
—###— +++++++++ +++###+++
–#####– +++++++++ ++#####++
—###— +++++++++ +++###+++
—-#—- +++++++++ ++++#++++
Now, I've tried to do this a number of ways. Simply ClipBlitting it with a
minterm of 0x60 didn't seem to me as likely, but that was labeled a "cookie
cut" blit, so I tried it, with awful results. (I suspect it did what I wanted,
but on a per-bit-plane basis, so that not every bitplane was overwritten with
the source imagery…)
I tried using BltMaskBitMapRastPort with a minterm of 0xC0, which I thought
would do the job correctly, and it did indeed copy the exact Source imagery
into the destination correctly, but it seems to change the area not covered by
the mask to something else also. (I'm not sure what, exactly – the remaining
destination bits all seem to be set to a solid color, NOT Color 0…)
Since this has been giving me a headache and I'm packing it in for the
afternoon, I figured I'd post a message here to see if anyone else has done
this and can help. I know it's possible – Deluxe Paint, for example, uses it
all over the place with it's brushes…
–>Steve Bennett
Steve,
You need to create the mask. If you've got 8 bitplanes, it takes 4
blits to do.
Actually, I *have* the mask. Since the images being blitted are all out of a
single data file, I made up a second set of images for the mask, all one bit
plane, when I decided to try to use BltMaskBitMapRastPort(). What I *don't*
understand is why the results turned out the way they did. I would expect that
a call like this:
BltMaskBitMapRastPort(&mybitmap, 0, 0, destrastport, x, y, w, h, 0xC0,
mask);
where, for example (each digit being a color):
mybitmap contains: 00012321000
mask contains: 00011111000
destrastport is: 45454545454
we end up with: 66612321666
This makes no sense to me. I would expect a result of 00012321000 or a result
of 45412321454 (which is my goal in the first place), but have no idea why the
outer edges end up as some color other than the background color or the
original destination colors with this call.
–>Steve Bennett
Steve,
I just checked some old source code (from The Perfect General), and I'm
using a MinTerm value of 0xE0 for my cookie-cut blits (using
BltMaskBitMapRastPort().
Hope this helps….
– BobR
(Motorola Inside!)
Thanks. I'll give that a try…
–>Steve Bennett
(One of these days I'll figure out those &^%$& minterms… <g>)
Many thanks! Changing the minterm to 0xE0 made it work like a charm. I still
have no idea *why* it works. I may try and figure it out at some point, but
not tonight… <g>
–>Steve Bennett
Steve,
I _used_ to understand how (and why) it worked, but it's been much too long
since I've been buried in Amiga code that I've pretty much lost it. At least I
still have the old code sitting around that I _know_ works, even if I don't
know why it works.
Glad I was able to dig it out for you.
– BobR]
Steve,
According to the AutoDocs on BltMaskBitMapRastPort:
minterm – either (ABC|ABNC|ANBC) if copy source and blit thru mask
or (ANBC) if invert source and blit thru mask
So, I make it 0xE0…but simpler to #include <hardware/blit.h> and use the
equation as written.
0xE0 did indeed do the trick. Bob Rakosky pulled it out of some code
he had written and let me know yesterday. Since then I managed to
wade through some docs on the blitter and understand where the 0xE0
came from (ABC|ABNC|ANBC) but I still don't understand *why* it works
that way. I tried various combinations of A, B, and C trying to
figure out which was the source, which was the destination, and which
was the mask, but I couldn't come up with one which worked. <sigh> I
guess I'll just follow the docs blindly for now… –>Steve Bennett
Steve,
In many cases just doing what the docs say is the best policy <grin>.