Just want to confirm that basics of proper gauge lighting.The following should be done:BITMAPS-------An alpha channel is created masking those areas that will be luminous at night. (bmp in imagetool will look black over areas being illuminated luminous)In MACROS---------Use IMAGE_USE_LUMINOUS for those elements which should be luminousIn Gauge Callback-----------------Do something like this: case PANEL_SERVICE_PRE_UPDATE: // Update gauge lookup_var(&panel_lights); if(panel_lights.var_value.n) { LIGHT_IMAGE( pgauge->elements_list[0]->next_element[0] ); } else { DARKEN_IMAGE( pgauge->elements_list[0]->next_element[0] ); } break;To each element as required. The above merely doing so for the first element above the STATIC background. I think I'll create a loop to just do it for all of the elements until NULL.If the above is done, then the gauge will be 2D and VC ready.Finally, follow Bill's VC lighting tutorial to create emissive lighting in the VC.Did I miss anything?Do you guys generally create a whole set of separate night bmp's rather than just use the day texture with BRIGHT?Handy how the panel bmp's are lightened for you by FS, but to bad that to create proper flood lighting is a royal pain esp. if your switches don't fit in neat little holes.Patrick

I use a slightly different approach myself, not caring overly much for the LUMINOUS tag, and it's dependence on the panel.cfg entry. Although, it does allow more 'flexibility' since the end user can 'tune' the color & brightness to their own tastes... ;)Instead, I use Photoshop's Render Lighting Effects to create night lighted versions of the various gauge elements as needed. Often, I will create two "levels" of brightness if I wish to have bi-level lighting control (off/dim/bright).Instead of building a pelement list as shown above, I simply add the code needed in each element's callback as appropriate: if ( panel_lights == 1 ) { SHOW_IMAGE(pelement) ; LIGHT_IMAGE(pelement) ; } else { HIDE_IMAGE(pelement) ; }Alternatively, you can use the pelement tree-list method as discussed in Dai's tutorial. Frankly, I prefer the method I use... ;)

>I use a slightly different approach myself, not caring overly>much for the LUMINOUS tag, and it's dependence on the>panel.cfg entry. Although, it does allow more 'flexibility'>since the end user can 'tune' the color & brightness to their>own tastes... ;)Yes, I like that feature too somewhat, but then also gives them something to screw up and call us about, haha.>Instead, I use Photoshop's Render Lighting Effects to create>night lighted versions of the various gauge elements as>needed. Often, I will create two "levels" of brightness if I>wish to have bi-level lighting control (off/dim/bright).Hmmm I have yet to discover this tool or plugin, I'll have to look for that.>Instead of building a pelement list as shown above, I simply>add the code needed in each element's callback as>appropriate:>> if ( panel_lights == 1 ) > { > SHOW_IMAGE(pelement) ; > LIGHT_IMAGE(pelement) ; } > else > { > HIDE_IMAGE(pelement) ; > }>>Alternatively, you can use the pelement tree-list method as>discussed in Dai's tutorial. Frankly, I prefer the method I>use... ;)Oh, silly me putting it in the gauge callback, which I didn't really want to do as it moves it away from encapsulation and creates more hoops with less cpu cycles.Funny thing was that I had mistakenly ruled out putting such code in the element callbacks as I thought it would not be called when the light switch was thrown. Silly me forgot that it will be called each time the element is drawn. (I confused myself with mouse callbacks probably).Yes, so one could easily set up the different versions in separate elements, and then easily control them in their indivdual callback. With my annunciators I used a different technique, actually using one element with multiple bitmaps and just adding a constant like this: #define OFF 0 #define DIM 1 #define BRT 2 if(isPower) { isLow = pelement_icon->source_var.var_value.n < MIN; isHigh = pelement_icon->source_var.var_value.n > MAX; if(isCautionLtTestBtnPushed | isLow | isHigh ) { return isDimmerBrt ? BRT : DIM; } } return OFF;which allows me to have the icons in one element (with 3 instead of 2 bitmaps), and the callback selects the dim or bright bmp. These have the IMAGE_USE_BRIGHT always set as they are lights, but I could adapt this and use it like the above too I guess.Might be cleaner to have them in their own elements. I too don't like the "tree".Thanks,PatrickP.S. Be sure to look at the image problem post, as I solved it.

Here is an example of bi-level lighting bitmaps. Gauge is the Liberty XL2 VSI. Liberty's gauges use a cool blue LED ring around the circumference of the gauge face. The effect is really stunning:http://img84.imageshack.us/img84/1932/xlsvsi3or.jpgIn this example, the lighted versions were created using the lighting filters of XaraXtreme, a vector based image drawing system.

Thanks Bill, a piture speaks a thousand words. I stayed up and played with that plugin last night, it's really cool, and now I can do lots I couldn't before.Those are really awesome looking too. (Hmmm last time I said that I was talking to a girl :-) )Patrick

I have another question now that I have finally finished re-doing my gauge in photoshop and am about to experiment with lighting, shadows, and highlights.Originally, I created a photoshop layer that is all black and placed it over other gauge element layers and used the transparency to control how much light "emitts" to the final .bmp of that sprite element.Now I am thinking that I can just create a sprite in the gauge that mirrors the element in movement, and is a dark overlay of that gauge element. Either just baked into it, or perhaps using the alpha channel to define the level of transparency.Do something like this? // Highlight MAKE_STATIC ( ) // None moving white w/ alpha // Shadow MAKE_STATIC ( ) // None moving shadow black w/ alpha // Night overlay MAKE_SPRITE ( ) // Darkens image with black image // using alpha channel (or baked in) // Or maybe this could be a dynamically // created GDI+ element allowing us // to create any level of lighting! // Gauge element MAKE_SPRITE ( ) // Normal gauge element // Gauge Background MAKE_STATIC ( ) // Normal background bmpGoing to experiment today with all this.Patrick

You can swap out the IMAGE_USE_LUMINOUS and IMAGE_USE_BRIGHT flags on-the-fly, giving two levels of illumination (plus Off) per gauge without resorting to multiple bitmaps. There is a catch (isn't there always?) in that the flags cannot be added to or removed while the lighting system is active, so you kill the lighting system, swap your flags and turn the lighting system back on. It will be detailed in the next release of sd2gau; I'm at work ATM and I can't remember the code I used.For multiple levels of dimming MAKE_ICON is really the best way to go. I devised the tree method of dimming back in FS98 days when Microsoft Orange was the only lighting choice you got. I still can't figure out why if I thought of something so simple, why didn't they?-Dai

>You can swap out the IMAGE_USE_LUMINOUS and IMAGE_USE_BRIGHT>flags on-the-fly, giving two levels of illumination (plus Off)>per gauge without resorting to multiple bitmaps. There is a>catch (isn't there always?) in that the flags cannot be added>to or removed while the lighting system is active, so you kill>the lighting system, swap your flags and turn the lighting>system back on. It will be detailed in the next release of>sd2gau; I'm at work ATM and I can't remember the code I used.IMAGE_USE_LUMINOUS * Only makes luminousity available. Sure you could turn it off/on, but then luminousity is always on (at least the radioactive kind) * Must be used in combination with an alpha chanel in the image * Depends on entries in panel.cfgDai, I have code that currently switched the flags out without regard to anything such as the lighting system (whatever you mean by that). To be honest, I often find your choice of words and or descriptions very cryptic and idiosyncratic, and so you are difficult to understand without an example of your meaning.>For multiple levels of dimming MAKE_ICON is really the best>way to go. I devised the tree method of dimming back in FS98>days when Microsoft Orange was the only lighting choice you>got. I still can't figure out why if I thought of something so>simple, why didn't they?I have found no reason to resort to such complexity yet as I have found simple and clean ways to do everything I have been attempting.Patrick

>You can swap out the IMAGE_USE_LUMINOUS and IMAGE_USE_BRIGHT>flags on-the-fly, giving two levels of illumination (plus Off)>per gauge without resorting to multiple bitmaps. There is a>catch (isn't there always?) in that the flags cannot be added>to or removed while the lighting system is active, so you kill>the lighting system, swap your flags and turn the lighting>system back on. It will be detailed in the next release of>sd2gau; I'm at work ATM and I can't remember the code I used.Actually, I think you just have to issue the REDRAW_IMAGE command to force the change. Something like:LUMINOUS_IMAGE( my_PGAUGEHDR->elements_list[0] );LUMINOUS_IMAGE( my_PGAUGEHDR->elements_list[0]->next_element[0]->next_element[0] );REDRAW_IMAGE( my_PGAUGEHDR->elements_list[0] );Doug

It's going to redraw next game loop anyway, so not sure why I would need to do that. I don't need it to update instantly.The gauges get redrawn often enough for me, at 18 Hz, so if I turn off that flag, then the next time it gets drawn it will be ok.I suppose if I were updating it at a slow rate, like once per second, then it would be good to invalid it so it draws right away.Patrick

I take a slightly different approach:case PANEL_SERVICE_PRE_INSTALL: if (!gaugeInstance) gaugeInstance = GetModuleHandle("Citation II.gau"); // Windows API call if (gaugeInstance && !elec2_base_bitmap) elec2_base_bitmap = new Bitmap(gaugeInstance, (WCHAR*)MAKEINTRESOURCE(ELEC2_Rec0)); // GDI+ callbreak;Now that I have a handle on the bitmap (pun intended), there's a lot I can do to play with it before redrawing... ;)

Which just goes to prove how out-of-date and behind the times I am after a three-year layoff - things have advanced greatly in that time even if the current FS version is still the same. I have to agree about the idiosyncrasies but I do try to avoid being cryptic. Anything that goes into the tutorials is just one way of doing it and probably never the best way of doing something; simply what I perceive the easiest way for a beginner. It's looking like much of that may now be out of date because you guys have well overtaken me by now and come up with things that are much better/easier. :)-Dai

Oh, I somehow doubt that. Many of us still consider ourselves rank beginners, however much we may have accomplished... ;)Like the old adage about the blind squirrel, on occasion we can find an acorn in the dark!