C gauges in FS11

[taguilo 33]

>>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

[n4gix 4,947]

>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... *:-*

[WarpD 824]

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.

[Chuck_Jodry-VJPL 663]

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.

[byork 2,259]

What does "3PD" stand for?Bryan

[ddawson 35]

3PD - third party developer.Doug

[PhilTaylor 45]

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?

[Chuck_Jodry-VJPL 663]

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.

[PhilTaylor 45]

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?

[Guest Patrick_Waugh]

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

[ddawson 35]

Phil,"What Patrick said..." in #24.For myself, I would really just be looking to keep on being able to do the stuff in C/C++ that XML can't do - sound and file i/o coming immediately to mind.The pros' requirements may of course be a little more precise, so I'll have to let them speak for themselves, either here or elsewhere.Thanks for listening,Doug Dawson

[n4gix 4,947]

>What if we keep the ability to program new gauges in C/C++,>but the back-compat with existing gauges is an issue?Thank you, Phil. I for one have no problem with any minor changes that might be required to keep in step with FSvNext. Since 99.9% of the gauge code I write is FSX SDK compliant, and I don't have to work "outside the box," my work shouldn't be affected much, if at all.I'm fully cognizant that anything that's done must be done with the (potentially) far more lucrative ESP market, and I am fairly sure that ESP customers would be very upset to have their C++ work so quickly brought to naught... :)

[Chuck_Jodry-VJPL 663]

File=............ locations are the least complex problem to deal with i would suspect.

[WarpD 824]

I use the default Windows folder access code via the Shell API. All file read/writes are within the approved user folder area.As far as "access" is concerned, the only things we access are configuration/data files, audio (wav) files. FS offers no method for us to call for an audio file to be played... perhaps it should?With regards to eliminating GDI+... I sure hope you have something at least as fast and most definitely as powerful to replace it with. DirectX isn't the answer there... because DirectX isn't designed for 2D rendering. It would add a huge "overhead" code-wise to implement a simple 2D rendering of a CRT display full of text.

[beatle 0]

<>I'm not quite sure I understand this statement. C/C++ gauges have been available since FS95 (I wrote a large hunk of the code to support these things in that version, so I know of what I speak :-> ) whereas XML gauges were added in either FS2002 or FS2004 (I wasn't on the team for either of those releases, so not sure which one added them) - so seems like the C/C++ gauges had a audience before there even were XML gauges :->Not related to the above, but on the subject I've seen mentioned a few times in here of XML gauges being slow because they are interpreted, this is only partly true. For the 80%-90% of gauge tasks that XML gauges are designed to accomplish, the action is fairly common that if these gauges were written in C++, they would all have fairly similar looking code with different variables and constants. With the XML gauges for these types of things, that mostly similar code is contained in one place, the XML is parsed into some data structures, and that common set of code uses those data structures in place of the variables and constants in the original duplicated code. As with anything in computers, its when you're trying to do something in that remaining 10%-20% of gauge type tasks that aren't currently supported in the XML system that requires going to C++ (well, and then there are those developers that just prefer C++ because that's what they know - that group would generally include me, except I work here so I at least have to be able to read these things :-> ). I've seen mention of sound as one reason you have to use C++. If the XML schema were extended to support various types of sound triggers (button press/release, conditional based, lookup table based, etc), that would enable an additional group of gauges to at least be implementable in XML.!! Disclaimer: I have no knowledge as to if/when any such extensions to the schema might be implemented, I was just throwing out the first example that came to mind :-> !!Another possible option might be combining XML gauge front ends with SimConnect-client based DLL "processing" back ends, so you would still have a way to hook in C++ code for your gauges, they just wouldn't be gauges themselves (granted, this would require some additions to the SimConnect API over what's available now, including loading/unloading a SimConnect client via the aircraft.cfg/sim.cfg file :-> ).!! Disclaimer 2: I work out of my house on the east coast and I'm not working directly on the Flight product (I'm over in ESP-land), so haven't been in on any of these discussions, so if I happened to mention something and it actually happens, that was purely coincidental :-> !!