Bitmap color depth and IMAGE_FORMAT in C gauges

[Guest 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, // 1555IMG_16_BIT, // 565IMG_16A_BIT, // 4444IMG_24_BIT, // 888IMG_32_BIT, // 888IMG_32A_BIT, // 8888IMG_DXT1, // DirectX Texture Compression DXT1IMG_DXT3, // DirectX Texture Compression DXT3IMG_DUDV, // Pertubation dataIMG_MAX // keep this lastWhenever 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?

[WarpD 824]

I don't know why FS has the additional color depths since it doesn't support them. I don't know why developers create images with depth greater than 16bit.They are not supported by FS at all.

[n4gix 4,947]

Hmmm... I'd venture that this is a question best asked in the "newsgroup"... ;)

[Guest darrenecm]

>Hmmm... I'd venture that this is a question best asked in the> "newsgroup"... ;)lol...maybe so Bill.However, going on past experience, I doubt I'll get answers frpm 'official' sources because of a combination of everyone being too busy and apparently only one person who knows anything about gauges. The gauges newsgroup is somewhat of a ghostown to be honest. You can practically hear the wind whistling and the tumbleweeds racing down the street ;)So I thought I'd come over to trusty old AVSIM and throw the question out to the many wise minds that frequent this place :)

[n4gix 4,947]

Indeed, 'tis a ghost town. I've had some questions remain unanswered since last November... :-eek Another great mystery are the number of unexplained IMAGE FLAGS... I've noticed that Easy Gauge invariably places BIT7 at the end of every macro's IMAGE FLAGS list, which I have to assume is equivalent to IMAGE_BILINEAR_COLOR (why they don't simply use IMAGE_BILINEAR_COLOR instead of BIT7 is another mystery!).One of these days I'm going to have to experiment with these also:FORCE_LIGHT(element)FORCE_DARKEN(element)

[Guest bartels]

Once upon a time, antialiasing was introduced in FS but never documented in the SDK of that version (prob. CFS, it never had a SDK). So some found out, that BIT7 is the bit for anti alias. I called it once IMAGE_ANTIALIAS or similar (just another alias for BIT7) in my gauges.h. In later SDKs IMAGE_BILINEAR_COLOR appeared. Easy Gauge might not use the latest header files.FORCE_LIGHT and FORCE_DARKEN simply set/unset the light bit for elements. But that is sometimes not enough, so FORCE_.. also forces a redraw.

[n4gix 4,947]

Thanks for that bit of history, Arne. Yes, EG is still using the FS2k2 gauges.h file. I rarely use it anylonger except to quickly generate prototype, experimental gauges, or simply visually draw/create the mouse points. It's still quite handy for such things! ;)I'm wondering now whether it would be possible to use a ColorMatrix along with the SET_OFFSCREEN command to allow for constantly variable illumination of bitmaps?

[Guest darrenecm]

Here's another question for the mighty gauge brains in here.Arne has mentioned in one of his many posts in here over the years that once a gauge is loaded, the pointers to much of the data structures are constant pointer types, thereby preventing any alteration during run-time.Specifically, I'm referring to the pointer/handle to the bitmap surfaces we specify in our resource files seem to end up in the IMAGE_SET structure, which I would guess all you GDI+ gurus are using to access the hdc for your drawing surface using pelement->hdc (or a convenience pointer to it).Now, I'm assuming that the bitmap resource for our rendering surface is basically seen as a handle to a BITMAP type (as we specifiy in MAKE_STATIC macros) and loaded into the pointers in the structure of IMAGE_SET (or one of the other IMAGE style structures).My question is whether the panel system is 'hard coded' to accept nothing other than a *resource handle* to a BITMAP type and also whther it only ever looks for it in the resource files we attach to our gauge gauge projects? I for one would like to give the panel system a pointer or handle to a bitmap surface I have specified in memory on *my* terms :)Obviously the bitmap I would give it would have to be of compatabile format, but my thinking is that I could create a bitmap in system memory that I could pre-process before I pass it on. I need to do this to possible solve a problem I have with rendering text in OpenGL. All my text is coming out mirror-imaged along the horizontal axis.Because I'm rendering to a DIBSECTION I've created as a BMP file using standard image processing software, the bottom-up row-order of a BMP is likely the cause of this problem.If I override the method by which the panel system gets the handle to our bitmaps, I could simply load the BMP file myself into memory, then pre-process the pixel-buffer section to reverse these rows to top-to-bottom. I'd then give the panel system a pointer/handle to this bitmap.Another possibility is that I could create a bitmap in video memory and give the panel system a pointer or handle to this. That way it may be possible to get hardware acceleration working from OpenGL. However, my gut feling is that maybe security features of WindowsXP would prevent an in-process DLL (aka our gauges) from accessing video memory of the application it's attached too. It's worth a try though.Any thoughts o wise ones? :)