Translucent drawing (outstanding from SDL conversion)

[pedro-w]

The Allegro version had translucent drawing for the backgrounds of the speech bubbles etc. I did not implement this for SDL, just for expediency. Do we want translucent drawing back?

[OnlineCop]

I thought the transparency looked rather nice.

When the bg parameter of KDraw::draw_kq_box() is set to "BLUE" (no idea why it was named that), we enabled transparency, drew the grey rectangle, then disabled transparency again.

I'm not sure how the Allegro version did transparency, but I don't suspect it had anything to do with the RGB::a (alpha) channel of any of those pal[] entries in res.cpp, since BLUE has a value of 2, and pal[2] == { 8, 8, 8, 0 }.

I think translucency was fine (the names BLUE, DARKBLUE and DARKRED were misleading and should be renamed), but it doesn't really require it. It doesn't seem to severely obstruct anything in the background that the player needs to see.

If we were to re-enabled it, would we want to use the alpha channel of the colors already defined, or simply force the transparency to be a certain percentage regardless of the RGB::a value?

[OnlineCop]

Apparently, Allegro defined the transparency values passed to drawing_mode() as:

allegro/draw.h:29: /* flags for drawing_mode() */
allegro/draw.h:30: #define DRAW_MODE_SOLID             0    /* the default, solid color drawing */
allegro/draw.h:31: #define DRAW_MODE_XOR               1    /* exclusive-or drawing             */
allegro/draw.h:32: #define DRAW_MODE_COPY_PATTERN      2    /* multicolored pattern fill        */
allegro/draw.h:33: #define DRAW_MODE_SOLID_PATTERN     3    /* single color pattern fill        */
allegro/draw.h:34: #define DRAW_MODE_MASKED_PATTERN    4    /* masked pattern fill              */
allegro/draw.h:35: #define DRAW_MODE_TRANS             5    /* translucent color blending       */

In DRAW_MODE_TRANS, the global color_map table or truecolor blender functions are used to overlay pixels on top of the existing image. This must only be used after you have set up the color mapping table (for 256 color modes) or blender functions (for truecolor modes). Because it involves reading as well as writing the bitmap memory, translucent drawing is very slow if you draw directly to video RAM, so wherever possible you should use a memory bitmap instead.

I don't fully understand what that all means. But from what I can tell from the code, the only thing in all of KQ using transparency is this menu system (which probably makes sense since menus are used heavily).

Which also makes me wonder whether it would be worth it to have an entirely separate overlay bitmap (rather than the global double_buffer for everything) exclusively for things like the menus, and allow players to adjust the translucency value however they want?