Transparency Issues for Direct Color Virtual Buffers

The fg_vbtccopy() function works with fg_tcdefine() to define up to 256 transparent colors. For 256-color virtual buffers, the transparent color values directly correspond to the pixel values in the virtual buffer, so they simply don't copy any pixels with color values defined as transparent.

For direct color virtual buffers, fg_vbtccopy() cannot just treat the RGB pixel data as one of the 256 transparent colors, so it uses the virtual palette to determine transparency. If the pixel's RGB value does not have an exact matching entry in the virtual palette, the pixel is not transparent. If we do find a match, fg_vbtccopy() uses the index of the first matching entry in the virtual palette (this will be a value between 0 and 255). The transparency attribute assigned to that index then determines if the pixel is transparent.

The above scheme works very well if you have no duplicate entries in the virtual palette. However, when duplicate entries exist, only the first (lowest numbered) of the duplicate color values can be made transparent. Consider the case of the default virtual palette, which has entries 25 and 255 (among others) defined to be white. You cannot assign different transparency attributes to colors 25 and 255 because any white pixel will first match color 25 in the virtual palette and will thus use its transparency attribute. To make a higher-numbered white color transparent, you could use fg_setrgb() or fg_setdacs() to change the virtual palette entry for color 25. Note that this is only necessary if the duplicate colors require different transparency attributes. If the duplicate colors all use the same attribute, it doesn't matter which duplicate color is selected when determining transparency.