for really good 24->16 conversion, you should look into color dithering. if you're not familiar with this, it's the principle that adjacent pixels, when looked at from far (or high resolution), "blend" together to form a 3rd color (the average of the pixels). A big bitmap of checkered black and white pixels would look grey in a high resolution display.

the only problem with dithered images is that when you zoom out, most algorithms work in such a way that some white or black pixels show up "alone" and stick out a little...

but dithering is pretty complicated, so for more basic (and still effective), you just need to modify your macro a little to this:

#define RGB16BIT(r,g,b) ((b >> 3) + ((g >> 2) << 5) + ((r >> 3) << 11))

[This message has been edited by foofightr (edited November 25, 1999).]

Basically, the last post got it right. You start out at the top left pixel, and you chop the lowest three bits of the red component and store it in the new 16-bit bitmap. Then, however, you take those bits you chopped off and distribute them to some/all of the surrounding pixels in the original bitmap (easiest is half to the pixel to the right and half down). You do this across the first row, then, starting the last pixel of the row below, go to the left, instead passing the pixel error to the left and down. You zig-zag down the picture in this fashion, and in the end the resulting 16-bit bitmap is VERY accurate and has very little distortion/banding/color errors etc.

- Splat

To me it's kinda dumb to do half the work of the macro while passing its arguments. The only way I can see your macro working is if you use it like this:

short mycolor = RGB16BIT(_24bit.red >> 3, _24bit.green >> 2, _24bit.blue >> 3);

with mine, you use it like this:

short mycolor = RGB24to16(_24bit.red, _24bit.green, _24bit.blue);

.. this lets the macro do all the work

Hope this helps

P.S. Splat: you know what I mean about the "zooming out" thing?

Josh

If that's not what you are talking about, then I suggest using a bit more advanced error passing strategy. If you are not zig-zaging across the bitmap (left to right then right to left) then you cannot get away with the simple 50/50 error passing I described above - you must pass some on the diagonals downward, both to the left and right.

- Splat

Vader

Let's start at the top left pixel. Looking at the 8-bit source red component, we see that it is 10111011 (187). So we shift it down to the 5-bit version 10111 and put that in the right place in the destination bitmap. But look, we cut off 011 (3) from the value. So, let's distribute that to some near by pixels (let's assume zig-zag down and right). So, we'll add 2 to the pixel to the right and 1 to the pixel below the current one IN THE SOURCE BITMAP. So in effect the total sum of the source bitmap remains the same because whatever we cut off we put somewhere else.

By continueing across the first line, we do our best to calculate the best colors given the 5-bit color space for each pixel. Good! However, in most every case we weren't exact. So, for example let's say EVERY pixel we underestimated the color value. So the next row will make up for that since we INCREASED the color values in it.

I'm sorry if that was unclear. There are many FAQs on this topic, some even here at Gamedev.Net I think.

- Splat