Questions Around Gauge And Dll Programming

[WarpD 824]

I can beat OpenGL performance... not with GDI+.... but I can beat it.DirectX isn't a viable process in FS... because apparently ACES doesn't want it to be.I think your expectations regarding FSX is unrealistic. :(

[Guest darrenecm]

I can beat OpenGL performance... not with GDI+.... but I can beat it.DirectX isn't a viable process in FS... because apparently ACES doesn't want it to be.I think your expectations regarding FSX is unrealistic. :(

So you've done comparative tests with OpenGL and some other API? What were your findings on performance figures? Particularly with OpenGL compared to GDI+? And I assume you're keeping whatever you beat OpenGL with a secret? Of course writing your own software renderer is a surefire way to go but that would require quite a bit of effort to implement and then subsequently maintain. My goal for now is to find an existing alternative to GDI+.As for DirectX, well I never even bothered trying to get that going because the boilerplate code required just to get DirctX set up is a headache. If DirectX were to be implemented for gauge drawing it would probably need to be done at a deeper level within FSX and be part and parcel of the DirectX processes used by FSX to render the world view.As for unrealistic expectations, you're probably right if you are hinting at Microsoft's / ACES reluctance to spend any effort on improving and enhancing the lot of C++ gauge programmers - no harm in discussing and hoping things change. Maybe Microsoft will listen if more people also wish for change. To be honest I thought there were enough 3PD's out there creating aircraft with complex gauges able to persuade Microsoft to improve things more drastically than they have for C++ style gauges in each iteration of Flight Simulator. By all acoounts it's been extremely difficult to get any technical information and clarifications regarding C style gauges and the gauges.h from Flight Simulator developers over the years. It's only since the later years of FS2004's life and now FSX and ESP that we are seeing much improved developer discussion (via blogs) and even MSDN coverage of how to design and develop add-on gauges.Not being privvy to the entire inner workings of how FSX actually consumes the gauge DLL files, maybe I'm being naive in thinking all we need is for the option to have a surface on which to render residing in video memory rather than just having a HBITMAP pointer to a surface in system memory, and for the fsx panel system to look to this surface in video memory when rendering gauges to the main screen when we have indicated that we are usinng such a surface in our gauge dll code. Until someone tells my why it is technically impossible for such a surface to be added to the SDK then I'll continue to wish :)

[Guest Doug Moldenhauer]

Thanks for the responces regarding my question. I'm moving along and starting into the Vertical Speed Controller, and maybe try compiling a SDK gau module.I have one other question as I haven't see a reference to it directly in the SDK. Can I create a user defined variable and transfer data to and from the gau moduleand the gauge xml file?I'd like to use this for a few things. For example I'd like to use a pushbutton or switch send its status to the gau logic to turn on the Speed Hold or Vertical Hold mode?It would also be helpful to locate the Gains and the Limits for the Autopilot in the xml file for easyier manipulation in the future.Thanks in advance Doug

[dragonflightdesign 98]

Much like the reason why many of you are using GDI+ instead of plain vanilla GDI.

I very much hope I either misread or read a misprint on a Microsoft statement about Windows 7 recently; it stated that they are dropping GDI+ (something to do with the resources required to do the redraw) but are keeping the bog-standard GDI.-Dai

[WarpD 824]

Just an FYI... I don't use an hbitmap or an hdc for GDI+ rendering. :(

[Guest darrenecm]

Just an FYI... I don't use an hbitmap or an hdc for GDI+ rendering. :(

Such a tease Ed :( That shows how much I know about GDI+. I thought GDI+ demanded a HDC in order to initialise and work properly. I thus assume you are directly manipulating a bitmap that is tucked away inside one of the many structures inside gauges.h? Maybe you're even mixing and matching GDI and GDI+ (which is certainly possible) to drop to the GDI metal in order to get more direct control of drawing surfaces than is allowed by GDI+? Mixing GDI and GDI+ is something I recently started thinking about.I'm beginning to think that I should start looking a lot deeper at GDI+ as I start refreshing my rusty knowledge about OpenGL and learning the new tricks and features of Visual Studio 2008. If only to be able to fairly compare GDI+ against any other API that may interest me.You've certainly peaked my interest with your little 'admission', keep 'em coming :(

[Guest darrenecm]

I very much hope I either misread or read a misprint on a Microsoft statement about Windows 7 recently; it stated that they are dropping GDI+ (something to do with the resources required to do the redraw) but are keeping the bog-standard GDI.-Dai

That would cause no small amount of headaches for lots of people as they would have to make up for that by writing their own wrappers and classes around GDI to re-implement much of what yoiu already get with GDI+. As far as my knowledge goes GDI+ is, after all, mostly class wrappers around the GDI system which GDI+ sits on top of? Similar in principle to what the MFC does for native Win32 system functions? Can anyone confirm my understanding, or misunderstanding as the case may be?Unfortunately I have a sinking feeling that you may not have misread the Microsoft statement. The GDI/GDI+ systems are what render most of the Windows GUI (windows, menus, buttons etc). I would hazard the guess that Microsoft is moving towards a GUI drawing system that can take advantage of GPU hardware acceleration considering the market is flooded with such hardware. This would give them greater interface performance gains pretty much for free and make their operating system more responsive and sexier-looking - maybe even as nice as Macintosh OS :(Microsoft already made small steps to this end with Vista and the manner in which the Aero interface and other advanced GUI effects work in that operating system. It doesn't take much of a leap to guess that in Windows 7 they might be going the whole 9 yards, leaving the underlying GDI system to provide a level of legacy support for older displays, plotters, printers etc.Do you have a link to that Microsoft statement?

[Guest darrenecm]

Okay, after Ed's comment about him not using hbitmap or HDC in his GDI+ trickery, I decided to go dig into the GDI/GDI+ SDK documentation. I'm left with the initial impression that when creating a GDI+ Graphics object, you can actually specify a window handle (a HWND) for the Graphics object to use. My question then is, does each and every gauge window on a airplane panel have it's own window handle? I'm sure I'll be able to deduce this from the gauges.h declarations but for now I'm not at my machine that has the SDK installed.If so then I'm guessing that using this handle when creating a Graphics object for GDI+ to use would be a more direct way to choose a destination to render to rather than any associated bitmaps or dibsections, as I seem to recall using in the past in my past experiements while learning C++ and gauge programming in FS2004.Is my initial insight here on the right track or am I more off course than a Cessna in a thunderstorm with total system failures? :(Not sure whether I should start a seperate thread on GDI+ clarifications like this for those of us who are less than GDI+ gurus? If any moderators are here, feel free to move things into a more deciated thread. I'm certainly in need of a one-stop shop to head to in order to improve my dismal GDI+ knowledge.

[Rocky 128]

Okay, after Ed's comment about him not using hbitmap or HDC in his GDI+ trickery, I decided to go dig into the GDI/GDI+ SDK documentation. I'm left with the initial impression that when creating a GDI+ Graphics object, you can actually specify a window handle (a HWND) for the Graphics object to use. My question then is, does each and every gauge window on a airplane panel have it's own window handle? I'm sure I'll be able to deduce this from the gauges.h declarations but for now I'm not at my machine that has the SDK installed.

No, each gauge does not have its own window handle, there is 1 window handle for the panel.Eric

[dragonflightdesign 98]

The information from Microsoft was included in a review of the Windows 7 M3 beta published in the current UK edition of PCPlus, so no, there's no direct link to an MS site statement.-Dai

[ddawson 35]

Thanks for the responces regarding my question. I'm moving along and starting into the Vertical Speed Controller, and maybe try compiling a SDK gau module.I have one other question as I haven't see a reference to it directly in the SDK. Can I create a user defined variable and transfer data to and from the gau moduleand the gauge xml file?I'd like to use this for a few things. For example I'd like to use a pushbutton or switch send its status to the gau logic to turn on the Speed Hold or Vertical Hold mode?It would also be helpful to locate the Gains and the Limits for the Autopilot in the xml file for easyier manipulation in the future.Thanks in advance Doug

Doug,I think this addresses your requirement:http://forums.flightsim.com/fswiki/index.p...les_in_C_GaugesDoug Dawson

[Guest darrenecm]

No, each gauge does not have its own window handle, there is 1 window handle for the panel.Eric

Thanks for the clarification Eric. That sparked a thought in my head about taking this handle to the panel window and using some custom coordinate system to draw my own gauge windowing system, but then I started seeing complications for supporting undocking etc and got a headache ;)Has anyone also heard of Amanith (http://www.amanith.org)? It looks like it would be ideal for gauge drawing and is based on OpenVG (http://www.khronos.org/openvg/) but, sadly, it's a commercial implementation of OpenVG with licensing and royalty fees involved :(Still, it may be worthwhile keeping an eye out for any other emerging OpenVG implementations that would adopt a royalty-free position.From what I remember during my last attempts to get OpenGL working it was all a bit of a hit and miss experiment. I was also new to C++ and I struggled to understand the manner in which Flight Simulator consumed gauge DLLs, not to mention never being really clued up on DLLs in the first place. I guess one of the reasons the gauges.h header file is so littered with macros is to actually hide the DLL nature of the code, is this thinking right?Sadly I lost all my source code that I played around with during my FS2004 addiction so I'll be starting from scratch again. Still, the effort was worth it because I had a goal and it accelerated my C++ learning process because of it. I do vaguely remember much of my experiments getting OpenGL working revolving around the following structure in gauges.h

typedef struct ELEMENT_STATIC_IMAGE{    HEADER;    IMAGE_SET    image_data;    PIMAGE          save_buffer;    HDC               hdc;                                    // HDC for Win32 API DrawText    HBITMAP         hbmp;                                   // DibSection for Win32 API DrawText    HBITMAP         reserved1;    PIMAGE           reserved2;}

and also looking at:

typedef struct  IMAGE_SET{        PIMAGE  final;        PIMAGE  source;        PIMAGE  reserved1;        PIMAGE  reserved2;} IMAGE_SET, *PIMAGE_SET, **PPIMAGE_SET;

I remember pointing my OpenGL render context at the hbmp member, though I could be wrong. My memory aint what it used to be :)Is that hbmp not the best target for rendering? I got the impression that there was a lot of swapping and copying going on with the way FS2004 consumed the gauge DLL and used the information in this structure and was wondering what the other member variables were for (apart from the obvious hdc. It would be good to know if there are other ways to set up a drawing surface for a more direct way to draw. Has this been discussed in these forums? Any thread links would be helpful because I couldn't find much using Search.Anyone have any thoughts?

[WarpD 824]

And now you're asking about what the commercial developers do. :(

[dragonflightdesign 98]

Is that hbmp not the best target for rendering?

Some code I received recently from an extremely helpful commercial developer on this forum shows that he is using the hdc of a STATIC_ELEMENT as a drawing surface. This is also the method displayed by Microsoft in their ESP sample ESPDrawing GaugesUsingGDI+.zip found here. As I am reluctant to pass on such code without permission, you could try asking Bill for his GDI template. It may be possible to use the hbmp but I haven't tried it.-Dai

[Guest Doug Moldenhauer]

Doug,I think this addresses your requirement:http://forums.flightsim.com/fswiki/index.p...les_in_C_GaugesDoug Dawson

Thanks for the info Doug. I just saw this post. I almost missed it wading through all of this mess. Talk abouta flippin hijack. sheeeeesh