Okay, the explosion problem: We have either a (5 6 5) or a (5 5 5) value. We have to mix this colour with a colour . A scalar from 0 to 1, alpha_mix, describes how much each colour contributes to the final colour. The final colour, , is computed using the following formula: = * alpha_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) * can be precomputed and converted to a (5 6 5) or (5 5 5) colour value. The result of remaining operation, * 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, , 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) * 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 * alpha_mix, and then add_colour, which represents (1 - alpha_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).