Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!wam!bchin
From: bchin@wam.umd.edu (Weiyuan W. Chin)
Newsgroups: comp.windows.ms
Subject: Win 3.0 BitBlt Ternary Ops
Message-ID: <1990Jul3.230340.595@wam.umd.edu>
Date: 3 Jul 90 23:03:40 GMT
Sender: usenet@wam.umd.edu (USENET Posting)
Reply-To: bchin@wam.umd.edu (Weiyuan W. Chin)
Distribution: na
Organization: University of Maryland at College Park
Lines: 36

I've been playing around w/ Bitblt, using the different ternary
ops available (ie. SRCCOPY, SRCPAINT, MERGEPAINT, etc.) and I've
found a bug.  

SRCAND is supposed to do DSa, where D is the destination bitmap,
S is the source bitmap, and a is the AND operator.  Instead,
it does DSo, where o is the OR operator.  Someone goofed.
SRCPAINT is supposed to be DSo, and it's DSa.
If these were the only ones switched, it wouldn't be too big
of a deal... but others are switched also!!  

I looked in the old Win 2.0 DDK and the display drivers are
responsible for implementing Bitblt... And I'm using the
8514/A driver... so I tried Video7's 640X480X256 with the
same result.

I couldn't believe this slipped through beta...  I even
double checked the windows.h with the list of ternary ops
(5 or 6 pages worth!) in Chapter 11 of the Beta Win 3.0 SDK
manuals.

I don't have the release version of the SDK yet... Can someone
out there with the release version please test this?

BTW, SRCCOPY works...  and I think the XOR op work right also,
and since these two are the common ops, I think no one 
has really used all the other ops that are available.

PS.  I also tried inputting the hex codes for the ops... w/ no
luck. 


--
Bill Chin
University of Maryland College Park
internet: bchin@cville.umd.edu