Virtual 18-bit Color Tutorial

Virtual 18-bit Color

What it is, why is it so phat, and how to do it. Yes, we actually had to do this back in the days ... ah, those were the good ol' days of DOS. ;-)

What is Virtual 18-bit Color?

Virtual 18-bit color is any game programmer's dream come true. It solves palette management and converting all those files from raytracers, scannings, and hand drawings to one palette. By now you are probably drooling onto the keyboard, so I'll get started.

Remember Windoze?

Yeah, Windows. If you've ever programmed in Windows or know anything about Windows you know that for the most part the bitmaps used by Windows are device independent. That is they can be displayed on almost all monitors with all kinds of graphics cards. So how does Windows do it (minus the code bloating)? Simple.

Instead of just copying the bitmap from one location to the screen like a regular game does, every time it writes a pixel it computes a color index to the current palette that is the closest to the source color and writes that color index instead of the source color index. If the bitmap is truecolor (ie-> it doesn't have a palette and the numbers corresponding to the pixels are actual colors) this process is even easier. All Windows has to do is get a color closest to the current pixel color and write that, without worrying about getting an index into the bitmap. If this doesn't make any sense see below:

How Windows Displays Device Independent Bitmaps (palette bitmaps)

Get the palette index of the pixel in the bitmap
Get the color there
Compute the index in the current screen palette that's closest to this color
Write a pixel with this index

How Windows Displays Device Independent Bitmaps (truecolor bitmaps)

Get the color of the pixel
Compute the index in the current screen palette that's closest to this color
Write a pixel with this index

Note: This doesn't apply to truecolor DISPLAYS!!!

So What?

By using this technique you can write a graphics engine that is device independent and doesn't need to manage palettes. You can also use true-color bitmaps in a 256 color mode. Another advantage of this method is that if you use regular bitmaps, each bitmap can have its own palette and the bitmap can index that palette instead of the screen palette. Therefore there is no need to convert your bitmaps to one palette. The graphics engine takes care of all of that!!!

Isn't this slllllllooooooowwwwwwwww????

Yes, it is. That's where my library and algorithm come in.

My Algorithm

Basically to achieve this device independence, what is needed each time a pixel is written to the screen is to find the index of the closest color to the real color of the pixel. This process takes way too much time obviously.

But, what if you could precompute these values before the program gets started? That's exactly what we're going to do.

If you have an array as such:

char Colors[64][64][64];

For each color (r, g, b) there is a char value. So what does this value represent? The closest index, in the current screen palette, to the current color.

Now that we've got this to implement device independent bitmaps do this:

Get true pixel color in red green and blue components
Using these look up in the Colors array
Plot a pixel with the value from the Colors Array

So that's it huh?

Yes, but there are some things to note:

The palette takes 256 KB in memory and on disk. This is too much to handle for 16-bit programs
You need to write a program that precomputes the values (I already did this so if you use my library it's already written for you (actually everything is))
You need to rewrite all the bitmap drawing, loading, etc. functions

Why?

So why did I do it? Primarily because I wanted to make 3d graphics programming easier and to make special effects such as transparency and lighting.

More to come

Someone suggested using only 4 bit values (16 shades) for each RGB component. This would cut down the size to 32k and it would allow a game to use more than one palette. It would still keep about the same quality as well. This is a good idea, and i'll probably implement it in the next version when I get a chance.