Bitmap color depth and IMAGE_FORMAT in C gauges

[darrenecm]

In my work getting OpenGL rendering to C gauges I've always been mystified as to why the IMAGE_FORMAT enumeration that is used in the IMAGE structure in gauges.h lists so many formats as shown below:

IMG_8_BIT_MONOCHROME = 0,
IMG_8_BIT_INDEXED,
IMG_15_BIT, // 1555
IMG_16_BIT, // 565
IMG_16A_BIT, // 4444
IMG_24_BIT, // 888
IMG_32_BIT, // 888
IMG_32A_BIT, // 8888
IMG_DXT1, // DirectX Texture Compression DXT1
IMG_DXT3, // DirectX Texture Compression DXT3
IMG_DUDV, // Pertubation data
IMG_MAX // keep this last

Whenever I create a 24-bit image in Photoshop and use this in a MAKE_STATIC, the image is *always* sampled down to a 16-bit color depth by the panel system.

With this fact in mind I'm wondering why nearly all add-on developers create their panel and gauge artwork bitmaps as 24-bit when they are ultimately degraded to 16-bit? Wouldn't reducing them to 16-bit save on the users' disk space and avoid any possible time spent by the panel system in detecting that the bitmaps are 24-bit and then sampling them down?

To make things even more confusing, in Dai Griffith's tutorial documents, he says the following:

"According to the SDK you can create both 24-bit and 8-bit images in the same gauge and have them separated by &H500 (i.e. 500 hex) in the #define listing. This is completely wrong. The numerical separation of the 8-bit and 24-bit bitmaps is 500 decimal, not 500 hex."

I tried ensuring my 24-bit bitmaps in the resource file were seperated appropriately but they are still sampled down to 16-bit by the panel system.

As confirmation, when I'm initialisaing OpenGL I always use the following case statement to ensure pfd.cColorBits in my Pixel Format Descriptor structure matches that of the gauge:

switch(pScreen->image_data.final->format)
{
case IMG_15_BIT: pfd.cColorBits = 16; break;
case IMG_16_BIT: pfd.cColorBits = 16; break;
case IMG_24_BIT: pfd.cColorBits = 24; break;
case IMG_32_BIT: pfd.cColorBits = 32; break;
break;
} // END switch(pelement->image_data.final->format)

In all my debugging sessions I've never noticed the result *ever* being anything other than IMG_15_BIT.

In short, does anyone know whether bitmaps with greater than 16-bit color depth bitmaps are supported at all in gauges? If not, what's the point of all those other enumerated formats?

[matsis]

I generally stick to 8 bit custom color palette. This way image size remains very manageable and most gauges don't use all colors of the rainbow anyway so I ususally loose not a single color when changing from 24 bit to custom 8 bit.
I stick to the rule to never use more resources than absolutely necessary to get the job done nicely and efficiently. For me all this bragging about 32 bit textures, polycounts in the millions and such is nothing but starkly inefficient with not noticable difference to well-done designs.

[n4gix]

>"According to the SDK you can create both 24-bit and 8-bit
>images in the same gauge and have them separated by &H500
>(i.e. 500 hex) in the #define listing. This is completely
>wrong. The numerical separation of the 8-bit and 24-bit
>bitmaps is 500 decimal, not 500 hex."

Er, it is somewhat ambiguous... ;)

#define ELEC1_Rec0 0x1000
#define ELEC1_Rec2 0x1010
#define ELEC1_Rec3 0x1011
#define ELEC1_Rec4 0x10FF

#define ELEC1_Rec0h 0x1500
#define ELEC1_Rec2h 0x1510
#define ELEC1_Rec3h 0x1511
#define ELEC1_Rec4h 0x15FF

In any event, what is critical and should be taken into account is that those "high res ranges" are best avoided when assigning resource numbers, otherwise some truly odd and disturbing results may occur! ;)

1000-14FF OK

1500-1FFF NO!

2000-24FF OK

2500-2FFF NO!

etc.

However, if your gauge will only be used in FS9 and beyond, this rule no longer applies, since the low-res/hi-res schema no longer exists! ;)

As Mathias has mentioned, while I create my gauge artwork LARGE and with 24 bit color depth, I will resize the image to final gauge dimensions and convert to 8 bit in Photoshop myself, so I can have more control over the results.

It may take two or three attempts before I'm satisfied. Sometimes I have to apply a bit of "noise" to gradient areas before conversion to eliminate any color banding.