Okay, the explosion problem:

We have either a (5 6 5) or a (5 5 5) <r g b> value. We have to
mix this colour with a colour <r_mix g_mix b_mix>. A scalar from
0 to 1, alpha_mix, describes how much each colour contributes to
the final colour. The final colour, <r' g' b'>, is computed using 
the following formula:

<r' g' b'> = <r g b> * alpha_mix + <r_mix g_mix b_mix> * (1 - alpha_mix)

This is a simple, but expensive operation.  Here is one proposed method
for optmizing this operation.

The value (1 - alpha_mix) * <r_mix g_mix b_mix> can be precomputed and 
converted to a (5 6 5) or (5 5 5) colour value.

The result of remaining operation, <r g b> * alpha_mix, will be pre-computed
and stored in a 128k table (64k table entries * 2 bytes per entry). The
table is constructed as follows:

There are 64k table entries, so each value in the table can be indexed with
a 16 bit integer. This integer will be constructed using the 15 or 16 bit
colour value, <r g b>, and the alpha_mix value. First, the alpha_mix value
into an integer, alpha_int, using the formula 

alpha_int = floor(alpha_mix*15). 


alpha_int can have values from 0 to 15, so it can be represented in 4 bits.
cann this bits a3, a2, a1, and a0.

In the case of the (5 6 5) rgb value, 5 bits are used to represent red,
6 bits green, and 5 bits blue. Call these bits r4, r3, r2, r1, r0,
g5, g4, g3, g2, g1, g0, b4, b3, b2, b1, b0. 


15   14   13   12   11   10    9    8    7    6    5    4    3    2    1    0
-----------------------------------------------------------------------------
r4 | r3 | r2 | r1 | r0 | g5 | g4 | g3 | g2 | g1 | g0 | b4 | b3 | b2 | b1 | b0
-----------------------------------------------------------------------------

Bits r0, g1, g0, and b0 are replaced by a3, a2, a1, and a0. The information
that was contained in these bits is lost, so the bit values have been chosen
to mimimalize the error in the colour. The new bit pattern is

15   14   13   12   11   10    9    8    7    6    5    4    3    2    1    0
-----------------------------------------------------------------------------
r4 | r3 | r2 | r1 | a3 | g5 | g4 | g3 | g2 | a2 | a1 | b4 | b3 | b2 | b1 | a0
-----------------------------------------------------------------------------

This is the bit pattern used for the table lookup.

following psudio code algorithm shows how a pixel would be drawn on a 5 6 5
display.

pval = explosion_sprite_pixel_value
aval = special_effects_palette[pval] . add_colour;
rval = special_effects_palette[pval] . alpha_value;
pixel = screen_pixel_value
pixel &= 0xf79e			/* 1111 0111 1001 1110 */
pixel |= rval
pixel = alpha_remap[pixel]
pixel + = aval
screen_pixel_value = pixel


Explosion_sprite_pixel_value is a sprite with pixels that consist of 8 bit
offsets into the special effects palette. In the 16 bit version, each entry
in this palette has two fields; these fields are add_colour, the pre-
computed (1 - alpha_mix) * <r_mix g_mix b_mix> values, and alpha_value,
a 16 bit integer that contains bits a3, a2, a1, and a0 in the following
format:

15   14   13   12   11   10    9    8    7    6    5    4    3    2    1    0
-----------------------------------------------------------------------------
 0 |  0 |  0 |  0 | a3 |  0 |  0 |  0 |  0 | a2 | a1 |  0 |  0 |  0 |  0 | a0
-----------------------------------------------------------------------------

Bits 11, 6, 5, and 0 and masked off of the pixel value, the alpha value is
ored with the pixel value, this value is used to look up the value
<r g b> * alpha_mix, and then add_colour, which represents 
(1 - alpha_mix) * <r_mix g_mix b_mix>, is added to the result.

Both the alpha_remap and special_effects_palette tables are relatively
inexpensive to compute, so niether need to be computed and stored on disk.
This means the algorithm should be versatile enough to handle other 16 bit 
colour formats, such as (5 5 5).

