From: Danny Thorpe Subject: Re: double buffering problem Date: 15 Apr 1999 00:00:00 GMT Message-ID: <37169C11.3EED7F5D@inprise.com> Content-Transfer-Encoding: 7bit References: <7enrfo$6hc10@forums.borland.com> <370FED39.69AD@globacon.com> To: steve@globacon.com Content-Type: text/plain; charset=us-ascii Organization: Inprise Corporation Mime-Version: 1.0 Newsgroups: borland.public.delphi.graphics The reason transparency often fails with paletted devices is that Windows performs the pixel ROPS on the palette indices, not on the palette colors. So, if you want an xor / mask / xor transparency operation to work, you have to make sure that the palette entries at palette index N and xor inverse of N contain colors that are xor inverses of each other. (yes, it's insane) As to your comment about the reserved system colors being constant... those color values can vary from one machine to the next. In particular, some video drivers have a bad habit of setting the system colors to values that are not xor inverses of each other, so xor transparency fails. This was a major problem in Win 3.1 and Win 95, but less so now. That may just be because fewer people are using palette-based video modes now. -Danny Thorpe Delphi R&D Steve Bliss wrote: > In Delphi 3, only 4,16,24 & 32 bit color work correctly for > transparancy, 8 bit does not. I do not know if this is a Delphi or > Windows problem. > > There is probably a much simpler way around this, but for what it is > worth...: I got around it by double buffering my output to the screen, > i.e. before any palletes get in the way. > > It is worth noting that the 8-bit color mode is unique in the graphics > modes in that it has a variable color pallette (except for the first and > last 10 color entries which Windows reserves for the GUI). The 4-bit is > a fixed 16 color pallette, and 16,24 & 32-bit represent colors directly > in the bits making up the color value. > > Steve Bliss