Custom GAUGE Night Lighting

[badderjet 181]

Hi gurus,well, making a custom night lighting bitmap appear when master batt&panel lights = ON was a simple task.At least for the background image. There I used an ICON.But how the heck should that work for e. g. a needle??? :-hmmmYour help is much appreciated,Thank youEtienneBTW - I am talking about C gauges, not XML.

[Guest]

>Hi gurus, >>well, making a custom night lighting bitmap appear when >master batt&panel lights = ON was a simple task. >>At least for the background image. There I used an ICON. >But how the heck should that work for e. g. a needle??? >:-hmmm >BTW - I am talking about C gauges, not XML. I don't know anything at all about C gauges, having only worked with XML, but surely the same technique I've adopted would work...For needles, I simply use the same bitmap, but with the Bright="Yes" option enabled, and keyed it to respond to the same boolean conditions as the background images.I hope this is helpful!

[badderjet 181]

Hmmm, thanks :-), but I do not think that will work, coz a complete different bitmap should be loaded. I have two bitmaps for the needle: needle.bmp and needle_lm.bmp and that's the problem.The IMAGE_BRIGHT parameter will only 'change' the existing 'day' bitmap after a predefined, hardcoded pattern (or was it LUMINOUS what makes the gauges 'pink'? Not sure anymore, but that does not matter here.).Well for the scale this was easy, I have the 'day' bitmap on the MAKE_STATIC. Further I have a MAKE_ICON macro (Ok this is now for the C guys) and a simple callback which returns -1 when panel lights and battery are off. Otherwise is returns of course 0, so the ICON gets shown (the 'night' bitmap). But I the heck can't figure out how to achieve that with other macros.Thanks,Etienne

[Guest bartels]

Check the "SHOW/HIDE Macros" in the sd2gau13.zip tutorial. Also you can use SHOW_IMAGE(pelement) / HIDE_IMAGE(pelement) directly in the image callback function to this element (here a needle callback).Arne Bartels

[badderjet 181]

Ok I gotta try that now.Thanks,EtienneOh BTW - Does that mean I need two needle macros?

[Guest JeanLuc_]

Hi Etienne,yes, in that case, 2 macros and 1 common callback. The drawback of the show/hide is when the same gauge is referenced more than once in the same panel file. Only one get properly showed/hidden. At least, it is the case on mines compiled with borlandc when the show/hide code is executed during the UPDATE phase in the gauge callback. Maybe VC++ handles the global variables differently? any experience on this?Hope it helps!

[Guest bartels]

As fara as I know there shouldn't be any difference between VC and BCC compiled gauges in that respect. Do you use any global variables for your gauge, any variable defined outside the callback functions? The reason, is that anything outside the callback function is unique and not copied from one use of a gauge to the other. Try to use any variables inside the callbacks, possibly avoid static declarations inside the callbacks and it should work. At least the one I made with VC with this "double texturing technique" work even if they are placed several times on the same panel.Arne Bartels

[Guest JeanLuc_]

Hi Arnes,yes I used to have global variables (let's say defined at the top of my .c file, outside any function. If I understand you correctly, if I put my declarations inside the main gauge callback, then if one instance of the gauge on the panel updates the value of this variable, another instance of the same gauge on the same panel (could be a pilot side and copilot side altimeter for example being the same MyAltimeter.gau referenced twice in the panel.cfg file) will share the same value too? That is in fact when FS loads up the gauges, it allocate the same address space for all the "local/in the main callback" variables for all the same instances of the same gauge (in the the heap, in fact?) The problem is that since they are local within the callback, they are not accessible from another function in your gauge (such as an element callback for example or any other function in your code). The other potential problem is if your are dealing with a complex gauge with many many variables. Since being declared locally, and if taken from the stack, you might endup using a lot of the stak space. I do not have a clue if it might impact performances that much however. I was wondering about BCC/VC++ because they might handle local/global variables differently (heap/stack/malloc/BSS) from their STUB code when starting up. This might then affect the way each instance 'shares' the address space. I'm not sure neither on this.It just appears to me that I might not get the full scope of what the main gauge callback really is. I see it as a function (in the 'C' convention). i.e. it is called from FS, and return, on a regular cycle basis. As such, it has its local variable space and that's pretty much about it. But since the gauge is a windows DLL, and there is a 'DLLMAIN' (like a .exe 'MAIN'), things might be a little bit different for the main gauge callback. Am I wrong or right? I would welcome any opinion on this subject.

[Guest]

>The IMAGE_BRIGHT parameter will only 'change' the existing >'day' bitmap after a predefined, hardcoded pattern (or was >it LUMINOUS what makes the gauges 'pink'? Not sure anymore, >but that does not matter here.). I cannot see why IMAGE_BRIGHT would work any differently for C gauges as the equivalent tag of Bright="Yes" in XML. I simply coded the file so that that parameter is only used if the master battery AND the panel lights are ON.IOW, I simply duplicated the entire section that defines that particular element's characteristics, and use either the OFF or ON section of the code, depending on the state of the two switches.BTW, it is indeed LUMINOUS that will make the gauges (and anything else tagged with LUMINOUS 'pink' (or whatever color is specified in the panel.cfg file).In fact, I had briefly toyed with the idea to use LUMINOUS as a 'dimmer' version of the gauge illumination, to provide three conditions: OFF, DIM, and BRIGHT... However, I got tired, and never bothered to implement it... :)

[Guest bartels]

Hi,I didn't know how to deep I should dug in the structure of gauges, so I was possily a bit "shallow" .All FS later then FS98 allow the mutltiple use of gauges from a multigauge (NOT old Fs98 style) on one panel. They perform this by making a dynamic copy of the whole image element/mouse rectangle structure for each apperarance of the gauge. More precisely it is everything which is attached to the including the GAUGEHDR structure which is declared by GAUGE_HEADER_.... . What is not copied is everything what is not defined inside the image structure, that includes all global variables and also all callback functions, since these are also globally defined functions. This might look contradictuos to what I previously posted, but it's not. To get access to the dynamic copy of the specific element each drawing callback is provided with the pelement pointer. The main gauge callback is provided with the pgauge pointer to get access to the GAUGEHDR structure of the active representation of this gauge (you can step to all data needed from pgauge including mouse rects and image elements if the need arises). For Fs2002 new is even the possibility to access the GAUGEHDR data in a mouse callback function, check the GAUGEHDR_FOR_MOUSE_CALLBACK macro. So to get independent representations of one gauge in a multigauge, try not to use global variables, because these are only declared once, also all callback functions are instantieted only once, but this isn't a problem since if they don't use any static declared variables inside all variables declared in the callback are newly initialized each time it's called.As last, if you need to store individual information for each gauge representation, that can't be provided otherwise (pgauge,pelement,GAUGEHDR_FOR_MOUSE_CALLBACK) you still have the possbility to store up to 10 floats in the "user_area" array of the GAUGEHDR (also new in FS2002 I presume).I hope I wasn't too confusing, and this was what you wanted to know. As fara as I know everything I wrote here is completely independent of the type of compiler you use. I wrote about the dynamic copying already in sdkbugs.zip if that still exists in the library, most parts of it are incorporated in the sd2gau serie.Arne Bartels

[Guest JeanLuc_]

Hi Arne and thank you for the update. Actually this is what I figured out so we're on trak understanding the same. What I was indeed refering to is maintaining individual informatin for each gauge representation. Since the code is the same for each, how could I with the same code ensure the values I'm computing from are the ones for that particular gauge instance, and not this other one. I've totaly overlooked the user area. I will explore this. What would be a good example of being able to access the GAUGEHDR data in a mouse callback function, compared to not being able to do so? do you think of a particular problem that could be solved with these data available from the Mouse Callback?As for the latest SD2GAU13, I've not seen it in avsim. It was advertised as being available only at flightsim.com, that I can't access (nodes busy all the time). Any other link we might download it from?Thank you for your help!

[Guest bartels]

I was just at flightsim.com, on first try! Usually I need 10-20 tries, but it has improved the last months.I haven't done much with the GAUGEHDR_FOR_MOUSE_CALLBACK macro yet. I rewrote it a bit and added a second one which I really used:#define GAUGEHDR_FOR_MOUSE_CALLBACK(PIXPOINT) ((PIXPOINT) ? ((PGAUGEHDR)(((PMOUSECALLBACK)(PIXPOINT))->user_data)) : NULL)#define PMOUSERECT_FOR_MOUSE_CALLBACK(PIXPOINT) ((PIXPOINT) ? ((PMOUSERECT)(((PMOUSECALLBACK)(PIXPOINT))->mouse)) : NULL)(NOTE as #defines they have to be one line only, presumably the forum will wordwrap them at inconvenient places) The reason for the second was a throttle gauge with mouse dragging. I need the size of the mouse rectangle for this, and before I stored the pgauge in a gloabl variable and checked through pgauge->mouse_rect until I found the related mouse rectangle. For once it needs a global variable this way, and secondly it's a bit dangerous if you don't take extrem care which i you use. The first can be solved with GAUGEHDR_FOR_MOUSE_CALLBACK(), but both problems can be elegantly avoided with the PMOUSERECT_FOR_MOUSE_CALLBACK().I haven't found a simple way to reuse this throttle for all four possible engines yet, but possibly ther is a bit to make with the user_area, I'll have to see.Last point I wanted to add, you can treat the user_area not only as floats, but also as MODULE_VARs, if the need arises (MODULE_VAR and FLOAT64 have the same size in byte).Arne Bartels

[Guest bartels]

>Last point I wanted to add, you can treat the user_area not >only as floats, but also as MODULE_VARs, if the need arises >(MODULE_VAR and FLOAT64 have the same size in byte). ERROR: user_area can be treated as an array of UNIVERSAL_VAR not MODULE_VAR, sorry my fault.Arne Bartels

[Guest JeanLuc_]

Thanks Arne,I've just managed to download it from flightsim. Thx for the hints. Now, let's get back to work and try it all!Best,Jean-Luc