Archived

This topic is now archived and is closed to further replies.

nickpike

C gauges in FS11

Recommended Posts

So I asked Phil Taylor in another forum about C gauges in FS11.His response:"unknown at this time, all I can say is they will cause a lot of work if we need to keep them."Doesn't look good for C gauges :-)-Bryan

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

Thanks for clearing that up , i read the original and was not absolutely sure i had placed Phil

Share this post


Link to post
Share on other sites

>So I asked Phil Taylor in another forum about C gauges in>FS11.>>His response:>>"unknown at this time, all I can say is they will cause a lot>of work if we need to keep them.">>>Doesn't look good for C gauges :-)>>-BryanIf this is true, it will eliminate a great deal of commercial products.

Share this post


Link to post
Share on other sites

And quite a few developers, me included. I'm pretty sure I can find something else to do with my time and it won't be learning XML gauges.-Dai

Share this post


Link to post
Share on other sites

Well, it wouldn't surprise me that MS takes this kind of decision.It's a fact that the old C-style's macro structures used in panel-tied .gau/dll files have not been improved almost a bit since the old FS days. Instead, there has been a massive movement towards XML-style gauges, scenery, mission and similar kind of FS files; I believe MS-ACES has developed FS's internal routines - mostly C++ classes - that handle XML source files in a very efficient way, considering the simulator's overall performance.As current XML-format limitations are actually schema limitations, it's very possible that we could find XML stuctures which will make possible to manage file IO, graphics and sound in future FS versions; even FSX shows a lead in that way, with the combination of "master" C++ dlls and XML "custom" related files for panel management. Now, the very weak point of an XML based system is the lack of effective copy protection for the sources. Even though FSX gives the possibility to "precompile" XML gauge files, it's not secure enough when speaking of complex commercial projects. So we'll have to wait and see how things evolve in this area.Tom

Share this post


Link to post
Share on other sites

Such a comment would seem to paint ACES as being out of touch with the "3PD's" as Phil likes to refer to them as.Rest assured Phil, you need to keep them, even if you do have to change their structure going forward.

Share this post


Link to post
Share on other sites

>Well, it wouldn't surprise me that MS takes this kind of>decision.>>It's a fact that the old C-style's macro structures used in>panel-tied .gau/dll files have not been improved almost a bit>since the old FS days. Instead, there has been a massive>movement towards XML-style gauges, scenery, mission and>similar kind of FS files; I believe MS-ACES has developed FS's>internal routines - mostly C++ classes - that handle XML>source files in a very efficient way, considering the>simulator's overall performance.>>As current XML-format limitations are actually schema>limitations, it's very possible that we could find XML>stuctures which will make possible to manage file IO, graphics>and sound in future FS versions; even FSX shows a lead in that>way, with the combination of "master" C++ dlls and XML>"custom" related files for panel management.> >Now, the very weak point of an XML based system is the lack of>effective copy protection for the sources. Even though FSX>gives the possibility to "precompile" XML gauge files, it's>not secure enough when speaking of complex commercial>projects. So we'll have to wait and see how things evolve in>this area.>>Tom>>>>>>>The weakest point of XML is it is an 'interpreted' language and thus can not process data and information as quickly as a compiled language such as C++. Nor can you write extremely complex systems like a realistic autopilot and/or flight management system with XML. Simply 100% impossible.I shudder to think of how limited my current project would be if it was written in XML.

Share this post


Link to post
Share on other sites

>>The weakest point of XML is it is an 'interpreted' language>and thus can not process data and information as quickly as a>compiled language such as C++. This doesn't seem to be a real limitation for most -if not all- possible projects, considering there are so many elements that affect FS performance appart from gauges. >Nor can you write extremely>complex systems like a realistic autopilot and/or flight>management system with XML. Simply 100% impossible.>Well, your statement reveals how much of XML scripting's power is directly ignored by many people. But the fact is, using XML and C++ dlls combined like shown in the SDK, there is no limit at all to build the most complex system available in any aircraft. Now I'm starting to notice that ACE's staff is well aware of this ;-)>I shudder to think of how limited my current project would be>if it was written in XML.Ed, I can agree with you here :-)Tom

Share this post


Link to post
Share on other sites

Well... the current C++ DLL support was almost gone with FSX... so don't be holding your breath. You have nooo idea how much they intended to kill in module support.As for scripting power... that's a beautiful oxymoron in my opinion. Do you truly think a scripted file like a .bat(ch) file can be even remotely as powerful as a full-blown .exe(cutable) file? I hope not... seriously.XML performance can indeed reveal significant performance impacts... the G1000 on my computer crawls with frame-rate issues... whereas the Mindstar G1000 (c++ .gau) does not.

Share this post


Link to post
Share on other sites

>As current XML-format limitations are actually schema>limitations, it's very possible that we could find XML>stuctures which will make possible to manage file IO, graphics>and sound in future FS versions; even FSX shows a lead in that>way, with the combination of "master" C++ dlls and XML>"custom" related files for panel management.The primary drawback to such a "hybrid" system is that it simply shifts the computational, sound and file I/O to a futher layer of complexity, increases the memory overhead, and forces longer development time, all of which add up to increased costs. >Now, the very weak point of an XML based system is the lack of>effective copy protection for the sources. Even though FSX>gives the possibility to "precompile" XML gauge files, it's>not secure enough when speaking of complex commercial>projects. So we'll have to wait and see how things evolve in>this area.Indeed, this is the burr in the saddle. Absent the development of robust protection against reverse-engineering, the community will ultimately suffer, as developers exit the business.

Share this post


Link to post
Share on other sites

Ed, I didn't know they planned to get rid of DLL module support. Why was that?And please do not compare the scripting system of an XML gauge file with a batch file. Instead, think about this: a C compiled .gau contains optimized code that is going to be "loaded" by core FS functions embedded in its main executable files. An XML structured file contains tags and scripts that are going to be "interpreted" (put into memory stack) by other FS core functions located in the same executable files.Obviously there should be some kind of impact in performance when speaking of very complex gauges, but might be perfectly masked by other variables (like scenery, weather). In my case, loading the default G1000 (both MFD and PFD) yields a loss of 2-3 fps in full window (I have a notebook nw9440), which I find very tolerable.Tom

Share this post


Link to post
Share on other sites

>In my case, loading the default G1000 (both MFD and PFD)>yields a loss of 2-3 fps in full window (I have a notebook>nw9440), which I find very tolerable.The G1000 affects my system quite heavily (-10fps) vs. analog C172 panel. Also, the G1000 cannot by any stretch of the imagination be considered an especially complex gauge.

Share this post


Link to post
Share on other sites

Well, I have a similar loss (-7/8 fps) in windowed mode. Anyway I agree with you, the G1000 is a basic gauge, with just too many elements to draw.Tom

Share this post


Link to post
Share on other sites

>Well, I have a similar loss (-7/8 fps) in windowed mode.>Anyway I agree with you, the G1000 is a basic gauge, with just>too many elements to draw.Well Tom, I have worked closely with Stasi during the continuing development of his Mindstar G1000, and I can state with absolute certainty that there's no way under the sun that ACES could ever provide the necessary XML schema to allow all the funtionality that Stasi has put into it to be replicated, period.The very notion of OOP is foreign to the XML paragidm.

Share this post


Link to post
Share on other sites

>>Well, I have a similar loss (-7/8 fps) in windowed mode.>>Anyway I agree with you, the G1000 is a basic gauge, with>just>>too many elements to draw.>>Well Tom, I have worked closely with Stasi during the>continuing development of his Mindstar G1000, and I can state>with absolute certainty that there's no way under the sun that>ACES could ever provide the necessary XML schema to>allow all the funtionality that Stasi has put into it to be>replicated, period.>>The very notion of OOP is foreign to the XML paragidm.>Bill, I don't have Mindstar's G1000, I was talking of FSX default's, which uses fs9gps data. I've read some reviews and yes, seems it's a great piece of software. However, on comparative reviews with a similar product made in XML, seems there are not much gain in fps (+2), and has pros and cons like every other addon out there. I also don't know how far ACE would want to go in the expansion of his XML schema, however you should know that XML is not a language but a set of instructions specifically designed by a developer to suit his needs; and in this way there would be no hypotetical limits: might support a millon tags, could be used as a bridge to GDI+,sound,3D rendering, whatever. Would this be practical or not is another story.What I do believe after many test so far is these current limits in FSX schema can be solved by the XML-C++ module interfase. Whether you like it or not, find it ugly or inefficient is also another story. But the truth is, a software like the Mindstar G1000, a complete FMS system, even a COMPLETE airliner system could be perfectly built, technically speaking only. In one of his posts Chuck made reference of FS's current trend of going into VC 3d rendering for gauges, in where controlling code is hard coded into the model through Modeldef XML scripting. It seems there's no room for C/C++ within this vision; and IMHO it's a shame that XML-C++ module partnership is not supported by model XML so far.Tom

Share this post


Link to post
Share on other sites

>Bill, I don't have Mindstar's G1000, I was talking of FSX>default's, which uses fs9gps data. I've read some reviews and>yes, seems it's a great piece of software. However, on>comparative reviews with a similar product made in XML, seems>there are not much gain in fps (+2), and has pros and cons>like every other addon out there. In the current (beta) version of the Mindstar G1000, among the many features is the ability to create flightplans directly, just like RXP's GNS530/430, but not requiring a "helper" like the Garmin Trainer actually doing all the work!......Saving the flight plan...Flying the flight plan...Loading any FS9/FSX flightplanIt also draws its own map on screen not simply fetching the bitmap from the fs9gps.dll like others do.It short, when completed it will do nearly everything the "real" G1000 is capable of, including the remote data pad system, all in a completely self-contained system. ;)Having just spent considerable time examining the ESP SDK, I've discovered that if one substituted "FSX" wherever "ESP" has been used, it is ~96% identical to the FSX SDK SP2 documentation......right down to the complete C++ gauge information!http://msdn.microsoft.com/en-us/library/aa155301.aspx I'm beginning to sense that somehow this whole discussion is nothing more than a tempest in a teapot... *:-*

Share this post


Link to post
Share on other sites

Ok, I've done a bit of thinking about this... and while I'm not on the "inside"... I have a thought:Perhaps what Phil Taylor is talking about deals with security. With the release of Vista, Microsoft has pushed really hard to cut down on security holes in their OS. We saw a shift in FSX with the requirement for digitally signed gauge files.Perhaps Mr. Taylor was merely suggesting that due to security reasons compiled code might be removed. However, I don't think that's actually the case. The complexity of a great deal of 3PD add-ons are simply impossible with XML alone, thus even if one were to use an XML "front-end", it would still require a compiled code module on the back end.I don't think support for C/C++ gauge code is going anywhere. Maybe they're going to replace all the macro stuff with something more class based... but that's about it.That's my opinion, after much thought.

Share this post


Link to post
Share on other sites

All that seems missing at this point is a word from our sponsor, or was that the word ?, knowing Bill well i trust his instincts butthis thread has not had the lid put on it and a bit of clarificationwould be welcome.

Share this post


Link to post
Share on other sites

What if we keep the ability to program new gauges in C/C++, but the back-compat with existing gauges is an issue?Part of the problem is, what if we change how we deliver our files and our folder structure? Do existing gauges have "too much knowledge" of where things are today and we cannot make changes we want to?That is where we are on the discussion. No decision is made, and the developers who we regularly converse with will hear a lot more before any decision is made.Does that help clarify?

Share this post


Link to post
Share on other sites

Yes thank you, we have more an understanding of the problem and can presage somewhat better the consequences of the options and how best to work within a new framework, your team is not alone as there is a large brain trust with a vested interest in your success.

Share this post


Link to post
Share on other sites

another question is then "where else can things in the sim change with still enabling C/C++ gauge programming but not locking Aces in to 'exactly how its done in FSX'", does that that make sense?specific files and file system structure, memory locations, in memory structure sizes and field offsets - these are all some of things we would like the flexibility to think about changing but we need to understand how "fixed" the universe must remain.replacing GDI/GDI+ with something else is another one to consider.does this help?

Share this post


Link to post
Share on other sites

What I'd like to see is ACES change whatever they want to make the sim better, prior compatibility be damned... but still allow developers to develop in C++ (or even .NET).Security could be addressed by requiring signed code, provided it was $100, not $400.My view is if you (as a developer) departed significantly from the API, and "hard-coded" things to gain a competative advantage, then you may have to pay the price when the next upgrade changes something, and that's just to bad. On the other hand, if you stay within the API, then it is likely that changes, if any, would be fairly minor and insignificant should you desire to re-release for a current version.But, really doesn't matter much to me these days as I moved on to developing other things with more financial incentive, better documentation, and less hassle (ie I don't have to try to guess what MS is doing - like with .air files). Don't get me wrong, the newer SDK is a great step forward.FS is a great program, and a lot of fun to fly, but a real pain to develop for it. I love making models, so who knows I may keep doing that for fun.Patrick

Share this post


Link to post
Share on other sites