Fixed a long-standing Windows emulation bug this morning.

Afterlife uses a lot of DIBs and BitBlts to render its video using standard Windows GDI, and it mostly works well. However, ever since I first brought it up, the opening logo would not be displayed; you'd just get a black screen.

It turns out that the game composes its video to an intermediate 8bpp bitmap, which it then BitBlts to the screen. The logo graphic is another 8bpp DIB that is copies to the intermediate bitmap.

When doing a copy from one 8bpp bitmap to another 8bpp bitmap, I generate an intermediate 256-entry lookup table that maps the colors of the source bitmap to the colors of the target. This is necessary because you can't guarantee that the two bitmaps have the same palette.

Today I realized that at the moment when the game copies the logo bitmap to the intermediate bitmap, both bitmaps have color tables filled with all 0 (black). My logic in this case mapped every color in the source bitmap to the best matching color, which is color 0 in the destination (really, any color would match in this case, but 0 is preferred).

I'm guessing the game expects the bitmap in this case to copy the raw pixels 1:1 with effectively no translation. But how to square this with the need to map palettes?

I decided that when creating my mapping table between bitmaps, I would first check for each color n to see if a 1:1 mapping would produce the correct color (in this case black color n in the source maps correctly to black color n in the target for all cases), and if so, use that as the mapping. If the mapping isn't perfect, then scan the target palette to find the closest match.

Not sure if this is Windows' real logic here, but it makes a certain kind of sense, so I wouldn't be surprised.