How To program XML to C Interfaces

[n4gix 4,947]

>>Alexander Drawe>>Outstanding! Would it be possible for you to post the source>code for that gauge so I can learn more from it? I'm afraid>I'm a bit too "green" to manage on my own... ;)Better still, please contact me at n4gix@comcast.net as soon as possible.Bill

[Guest HartmannH]

Hi everybody,I need to put a GPS map in a gauge too. Unfortunately I didn't download Alexander's demo gauge before it was removed from the AVSIM server. Would someone be so kind and send me that file to hhartmann at fsfd dot de or just attach it to a new post in this thread (110228.zip was the original file name). Thanks a lot :-)

[Guest darrenecm]

I'm just starting out on getting my head around the SDK to create my own gauges and something has been bothering me from day one.This may be a naive question but if Microsoft has made efforts to allow third-parties to create add-ons for FS2004 by releasing this SDK, how come there is still so much useful functionality hidden away in undocumented dll files? This topic of having a moving terrain map in a .gau C/C++ implemented gauge is a specific example. A terrain map in an XML gauge like the default GPS is obviously relatively easy but why is it such a mystery in a C/C++ gauge? Or how about having the FS2004 flightplanner coloured terrain map shown in a .gau (or even XML) ND type gauge? That way you could use the elevation type terrain colouring for a psuedo TAWS.I'm confused as to why this kind of functionaility is so very well hidden and not covered in the SDK. Is it simply a case of time and effort on the FS2004 SDK authors part that they have't got around to telling us all how to talk to the various dll files that provide so much of the Flight Simulator engine information?It just all seems very inconsistent to me at the moment. Compared to other software titles that allow users to create content using SDK material (Unreal, Half Life etc), Flight Simulator's SDK appears ludicrously limited in scope, despite having the largest and longest-established add-on community. Will this ever change for FS2004 or do we all just have to hope things improve in the next Flight Sim release :)- DE

[n4gix 4,947]

In the case of the fs9gps.dll the answer is simple. MS never intended for anyone to use this .dll for C type gauges or they would have explained how to access it in their SDK.The .dll was programmed to provide GPS functionality for their XML GPS...

[Guest darrenecm]

Then that begs the question what was Microsoft's intention in not providing similar access to the map and terrain drawing functions that are readily available to XML gauges? Large tracts of the FS 2004 SDK documentation is on how to do things in C so it's odd that documenting how to access these functions from that language is absent. Is it that Microsoft intend to drop support of C based gauges altogether in favour of XML? I certainly hope not.I'm not at all convinced XML gauges can provide the kind of performance I want from certain types of instruments. It was a reasonable choice in the case of the default GPS. I believe even real Garmin 530's do not update in 'super-fine, pixel perfect and silky smooth realtime'. For 'performance instrumentation' such as attitude indicators, VSI or high-tech digital 'glass' instruments, fast performance is likely essential.I would also guess that these performance reasons are why you and Ike Slack at Eaglesoft towers are coding that exciting-looking Avidyne system for the Cirrus SR20 project in C - XML just isn't up to it? So quite why, as developers, you are forced down a gnarly path of trying to figure out how to get your C-based Avidyne gauge to show something like the FS terrain map, when it's done so easily in XML, is odd.Can anyone reassure this newbie gauge creator that the time I'm spending learning all this C programming trickery will not be in vain when the next Flight Simulator 200x comes along? Could it simply be a question of the current FS2004 SDK not being totally complete and maybe an updated version will show how to access everything from XML AND C...I certainly hope so :)- DE

[n4gix 4,947]

>I would also guess that these performance reasons are why you>and Ike Slack at Eaglesoft towers are coding that>exciting-looking Avidyne system for the Cirrus SR20 project in>C - XML just isn't up to it? So quite why, as developers, you>are forced down a gnarly path of trying to figure out how to>get your C-based Avidyne gauge to show something like the FS>terrain map, when it's done so easily in XML, is odd.To be perfectly honest, the primary reason for the C, C++ and GDI+ code is one of protecting our investment. There's simply no possible way to keep XML code from being "borrowed" by anyone with access to more than two brain cells and notepad.exe! ;)Well, that and the fact that XML is an "interpreted list of instructions" that must be continuously "re-interpreted and executed," which makes the code slow and cumbersome to run...Now it is certainly a fact that GDI and GDI+ are, relatively speaking, slow in execution as well, but it is likewise true that at the end, even XML "code" is parsed, "translated," then executed using conventional GDI blit techniques. At the end of the process, an XML gauge has simply added yet more overhead processing time and resources to accomplishing the same end result.Since the XML "engine" is wholly dependent on C coded .dll files, I think it is unlikely that MS will completely depecrate the C gauge system in the near future.

[spokes2112 179]

Bill,You wrote: "XML code from being "borrowed" by anyone with access to more than two brain cells and notepad.exe"Wrong there buddy... It takes 3.. One to keep the heart pumping, One to keep the lungs inhaling, and the other is left for code LOL!! :-)Regards,Roman

[n4gix 4,947]

>Bill,>>You wrote: "XML code from being "borrowed" by anyone with>access to more than two brain cells and notepad.exe">>Wrong there buddy... It takes 3.. One to keep the heart>pumping, One to keep the lungs inhaling, and the other is left>for code LOL!! :-)Ah ha! How could I have been so wrong! Thanks! You are quite correct in that timely correction. *:-*

[Guest darrenecm]

Lol indeed but I would say four are needed. Three for the already mentioned functions and one extra to contain a 'sense of humour'. Essential for those dark hours when your code is not doing what you blasted well want it to. Maybe even a fifth cell for motor functions to enable you to reach for that slice of pizza and the essential bottle of Dr Pepper. Gotta have sustenance to keep your limited supply of brain cells alive after all :)- Darren

[N400QW 205]

FS development does present challenges at every turn. A quick look thru any freeware or payware project shows that no developer that we are aware of has been able to implement the base and terrain maps from the default GPS in C/GDI+.We do have a primitive working base/terrain map in C/GDI+ but it is totally unreliable at this point.The fact that no one that we are aware of has overcome this challenge speaks to the difficulty involved:-)

[Guest darrenecm]

Hi Ron.It wil certainly be interesting to see if your Cirrus SR20 gauge gurus can find a way around this 'terrain map in a C gauge' issue for accurate representation of some of the optional features of the real Avidyne systems. With the developments taking place in the real world, moving map digital avionics are becoming more commonplace in GA aircraft. Hopefully a solution can be found so that Flight Simulator will be able to portray these real world developments.It just all seemed very odd to my untrained mind that an SDK hides features of the software engine from a more powerful lower level language like C, yet makes it accessible in a higher level interpreted language such as XML. It's usually the other way around :-newbieAs it stands it looks like developers such as yourselves may have to do a spot of creative thinking, liberally sprinkled with a dash of reverse engineering or dissasembly to hopefully overcome the issue. Which is kind of defeating the whole point of an SDK in the first place. Well at least my questions on this issue and the responses of greater gauge programming minds than mine are allowing me to get a better grip on what to expect down the line. Hopefully Microsoft will adopt a more consistent approach to documenting and exposing more variables and interfaces in the SDK to remove restrictions to creating the kind of advanced aircraft instruments that are becoming so commonplace. I believe Micrsoft recently advertised on the FS2004 website for users to participate in some kind of study? I missed the announcement so don't know what the purpose of it is. With any luck though it's an exercise to find out what people want in the next Flight Simulator release. I just hope there are plenty of gauge programmers in that study group and issues with the current SDK thoroughness and scope are being talked about :)- Darren

[N400QW 205]

"As it stands it looks like developers such as yourselves may have to do a spot of creative thinking, liberally sprinkled with a dash of reverse engineering or dissasembly to hopefully overcome the issue."Be assured that we are doing just that:-)

[martinboehme 492]

Does anyone still have the attachments that Arne included with his original message, or any information on how to implement your own CustomDraw elements?I'd like to implement a smooth antialiased ADI for the DMFS VC10, and it seems a CustomDraw element would be the easiest way to go... I tried doing the wohle thing as a GAU file, but because I can't use IMAGE_USE_TRANSPARENCY, the gauge has to be a rectangular shape... and the panel expects the ADI to be round. I could include parts of the panel bitmap in the ADI, but I think tweaking the XML gauge with CustomDraw would be a lot simpler...Anyone who can help me out...?Martin Boehme

[Guest Mathias]

Here you go, Martin.http://forums.avsim.net/user_files/149153.ziphttp://forums.avsim.net/user_files/149154.ziphttp://forums.avsim.net/user_files/149155.zip

[martinboehme 492]

Great, thanks Mathias!