Home
The Beginning Programmer's Page Virtual 18-bit Color Tutorial |
Virtual 18-bit Color
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)
How Windows Displays Device Independent Bitmaps (truecolor bitmaps)
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 AlgorithmBasically 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:
So that's it huh?Yes, but there are some things to note:
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 comeSomeone 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. |