C gauges in FS11

[n4gix 4,947]

><<>but XML,s limitations were what drove the use of c++ in the>first place and the removal of this format does not strike me>as a step forward>>>>>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 :->Tim, I think what was meant was that after XML was first introduced, and folks (eagerly?) began to implement it's use, the discovery of the actual limits to what could be done is what drove many back to C++ gauge code.Aside from the lack of file I/O and sound support, XML's very limited vector drawing set is a huge drawback. Such neat things as ARCS and gradient-blend art is non-existent...As for the XML<>C++ .dll support, that's already available (see the "Cabin Comfort" example in the FSX SDK), but it simply adds a huge layer of complexity onto the solution, with concommitant overhead "bloat" in terms of memory footprint. :(

[ddawson 35]

>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++ (...). 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.I think this about sums it up Tim. Because C++ gauges are available now, that 10-20% can be done. If support for these gauges is dropped, you will be setting back considerably the range of "stuff" that can be accomplished through gauge code. There's no way the XML schema will ever be expanded to include everything that can be done with C++. You'll end up being barraged with an endless stream of complaints about how we used to be able to do X, Y and Z, and now we can't.Doug Dawson

[Guest ziporama]

From what I can tell, C++ gauges are antiquated not from the standpoint of the language, but from the API and rendering, designed for a previous generation - glorified sprites, and GDI+ is the essential hack that got a breath of air to bridge the gap. This is fine with 2D panels, and has been a big hurdle for realistic 3D VCs. The C++ gauge interface was also designed as a very closed, proprietary API in terms of communication to the sim, thus prompting products like FSUIPC to get into it with diabolical hacks. This said, XML gauges are just about as antiquated, first because few of us want to speak reverse polish notation in a world of rapid app development (unless we want to return to the world of VI), and also the fact you need a solid language behind it to make it work. Does WPF entirely work in XAML? No, it can't. Same thing here.With SimConnect now exposing a normalized API for everything except graphics, it would be nice to see that continue to the next level.Two paths I'd like to see: First, I'd love to see XAML/C# integrated in FS11. Yes, there's a hit in performance with managed code over C/C++ (10 to 25% in my testing, 1 to 3 FPS in real terms). At present, the biggest hit is this constant marshalling going on between native and managed memory. If we could eliminate that, we can probably shave another 5-10%. It's possible to have a PID in C#, it's possible to render 3D in C#/XAML in FSX (would help quite a bit if we had access to the windowing API). What I like about this approach is that you also get real dialogs, threading (great on today's multi-cores), networking, a GREAT debugger, events, remoting, encryption, I/O, DirectInput, DirectSound, etc... Imagine developing your gauges using WPF/Simconnect style coding, without a major perf hit, that would be a big step towards agile programming in FS.The other approach that makes sense to me is to simply move all gauges into the 3D models (many are now doing this now, already bypassing the standard .GAU files, and getting major FPS gains as a result). At present, it also prevents a good portion of the add-on community out there from adding custom gauges to existing models. Perhaps making it easier to add custom gauges as MDL files with a support module (C++ or C#) would be a great thing.Just ideas.Etienne

[WarpD 824]

Ok... the first thing I'll toss out is let's not use this discussion as a method to push our "personal favorite" to be the "new standard".It's strictly a discussion of C/C++ with FSnext.

[ahuimanu 50]

>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>I'll admit maybe it is because I am too lazy or thick, but I can't muster any love for RPN (I agree with Etienne's comments in this regard in a post further up).It's a shame to hear this Dai, your work has been God-send.J-

[ahuimanu 50]

>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?Phil,Anything you can do to keep things manageable for the hobbyist and small-timer would be great. I realize you maintain connections with commercial FS developers - I hope you have contacts or representatives of the "little guys" too. On that note, despite Ed Wilson not wanted to hear of it, C#/.NET for gauges (perhaps which could then be compiled from MSIL/CIL to native binary) would not only work for the "little guys" but could radically improve productivity for the big timers too.On that note, if you could continue to support an affordable (I don't find 3DS Max to be affordable) modeling tool, that would be GREAT! :-)J-

[dragonflightdesign 98]

Thank you for that comment. I'm learning XML as part of the .Net MCAD program and I really cannot see how the schema could be successfully expanded to cover everything we are able to do today with C (yes, I'm a barbarian).-Dai

[Guest ziporama]

I think MS really bridged the gap well between XML and "normal" coding in XAML. Best of both worlds, and very few limitations.I still don't see how you can do everything in XML, even if I turn my computer upside down and look at the screen with a mirror and "speak like Yoda learn I shall".Etienne

[wchafe 0]

>What if we keep the ability to program new gauges in C/C++, but the back-compat with existing gauges is an issue?As long as you maintain the ability to create C++ gauges I have no issue with changes that would affect backwards compatibility. I just don't want to have to rework the vast amount of systems logic we've programmed over the years simply because C/C++ based gauges and modules are no longer supported. I think that would probably put an end to us. ;)I would also welcome a revamping of the 2D panel system. I think that's overdue. I wouldn't like to see it disappear in favour of a VC only system. I think there are far too many users who still rely on 2D panels for one reason or another. ;)Wade ChafeLevel-D Simulations

[WarpD 824]

>>>What if we keep the ability to program new gauges in C/C++,>but the back-compat with existing gauges is an issue?>>As long as you maintain the ability to create C++ gauges I>have no issue with changes that would affect backwards>compatibility. I just don't want to have to rework the vast>amount of systems logic we've programmed over the years simply>because C/C++ based gauges and modules are no longer>supported. I think that would probably put an end to us. ;)>>I would also welcome a revamping of the 2D panel system. I>think that's overdue. I wouldn't like to see it disappear in>favour of a VC only system. I think there are far too many>users who still rely on 2D panels for one reason or another. >;)>>Wade Chafe>Level-D SimulationsSorry Wade, I hate your plane... *hides his own copy* so I hope they force you to reprogram it in XML... or maybe FORTRAN. *cackles evilly*

[ahuimanu 50]

Wade,I totally agree with your reinforcement of the efficacy of the 2D panel system. The ability to open 2D panels, for the radio or FMC, and then place them on another monitor remains a vital part of the FS experience with your product and other's.J-

[ahuimanu 50]

The WPF might hold an answer but then you'd have to use that C# that you seem not too fond of.J-

[WarpD 824]

>The WPF might hold an answer but then you'd have to use that>C# that you seem not too fond of.>>J-What's "The WPF"... The World Pencil-pusher Federation?C# is not for developing DLLs. It's entire system is built around developing applications with a UI. Because of that it is not as powerful and simplistic to use as straight C/C++ is for a DLL.Proper tool for proper job.Considering C# is C++ with a Delphi class-wrapper library... *shrug*.

[n4gix 4,947]

>>The WPF might hold an answer but then you'd have to use>that>>C# that you seem not too fond of.>>>>J->>What's "The WPF"... The World Pencil-pusher Federation?Windows Presentation Foundationhttp://msdn.microsoft.com/en-us/netframework/aa663326.aspxNot something really suitable for FS gauge work though... ;)

[WarpD 824]

Ah... yes I'd looked at it when it was first released... more or less worthless for a GDI+ replacement.