• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

XML Bubble Sort utilizing XMLVARs

Status
Not open for further replies.
There is a pretty good tutorial out there....The ESP GDI+ example. It shows a basic OOP'ed gauge callback, along with everything needed to set up the gauge's link with the panel system

Its a slightly modified ESP GDI+ gauge project that I have been using as a template to build on for every single C++ project I have done so far.

Well, I thank you for that because...

Around the end of 2006, MS was looking for a 3rd party developer that would help them release the Acceleration Pack, so they started looking for candidates, and gave a roughly 1 month deadline to create a glass-cockpit sample, complete with source code, in order to select their partner.

Unfortunately, it was all during the holiday season and, that year, I took a *long* 3 weeks holiday, touring South America with my family. When I've got back, the deadline closed in less than 1 week, but I didn't want to miss the chance so...

3 days later, starting from scratch ( well, not "from scratch", from my trust set of C++ classes, that's the point... ), I sent the finished sample to MS.

They apparently liked it, since I was tasked to provide the programming for the F/A-18 gauges, together with the rest of the team (the people that were going to form FSDT the following year), and one of the things they appreciated more, was the Object-oriented approach.

What you are seeing in the ESP GDI+ sample, is a stripped-down version of the very basic structure of the F/A-18 code, but the concept behind were already in place with the Cloud9 MB339 and Phantom so yes, I think we might probably build on that, to provide additional C++ tips in this forum.
 
Just my 2 Cents from reading this topic.

XML can be easy to code for beginners and low complexity aircrafts.

Let me just illustrate an example:

Get Engine N1 Parameter:

XML-Use A: Vars and that's it.

C++-Add variable into Simconnect Data Structure, more keystrokes to add to data definition, Finally access the struct to get N1 data.

You can clearly see the steps and number of key strokes is way more.

However, that is for beginners.

For SEASONED C++ programmer won't have to enter all that as you probably already done that once before and can simply reuse old simconnect code which you probably entered lots of vars already.

Then comes the other issue of hybrid mix of xml and c++.

People who code in C++ will understand what a pain it is to declare an L: var, get the id then read it, especially if you already has tons of L: vars that you already use. (x 200+ for the number of vars)

One of the aircraft add-ons in the market that I had coded have 70% of the systems in XML including some of the most complex (VNAV), development of those systems were fairly quick, but the debugging was a pain.

However, If you asked me whether if I coded everything in C++, would I have done it faster, I will not be able to give you a definite answer, because some system are so simple that XML would be much faster to code, while the more complex systems, C++ would be blazingly faster because of the debugging tools.

TLDR; I wouldn't claim one programming language/script is faster over the other in all conditons. Use whatever that suits your aircraft complexity.

Sorry for the off-topic. :D
 
Enlightening, but have to agree with Dick that we have digressed. By now, the thread title belies all of the important debate.

One response in particular sticks out to me, and that is Doug’s remark that with C++ you’re on your own. A C++ tutorial would certainly be a valued addition to this community, but will subject matter experts have the time or commitment to ever do this?

Bob
 
TLDR; I wouldn't claim one programming language/script is faster over the other in all conditons. Use whatever that suits your aircraft complexity.

That's the point I was trying to make clear. And I agree with all you have stated.

In the current VC world you can take true advantage of C++ GDI+ and other advanced graphics tools only when working with glass instruments (PFD,MFD, etc). In standard "steamed" cockpits gauges are completely modeled in 3D (frame, needle,etc) so there is no room for C++ custom rendering; FS is in absolute control of .MDL graphical routines and this, AFAIK, cannot be changed whatsoever.

And when it comes to systems' logic programming, unless you are talking of a huge project (ie big irons like 777), there would be no visual differences to the end user whether the code is made in C++ or XML. Take a twin engine example- piston or turboprop - with custom autopilot and extensive simulation of different systems (elec busses,pressurization,hydraulics, etc); building the logic either in C++ or XML won't make a difference to the user; the impact of XML would be, in the worst, so minimal as to be negligible. The reason is very simple: processing of straightforward code consumes only a tiny part of the CPU resources, the biggest part is taken by the display routines. So making a choice as whether to go XML or C++ will probably depend on how much reusable code from other projects the programmer might use. For someone that has made lot of work in XML before, going XML would be the best option even though he could have started to play in the C++ arena. And otherwise, of course.


One response in particular sticks out to me, and that is Doug’s remark that with C++ you’re on your own. A C++ tutorial would certainly be a valued addition to this community, but will subject matter experts have the time or commitment to ever do this?

Bob, that is not entirely true. Dai Griffiths had written an excelent set of documents on building gauges with C++, working examples included. And there is lot of info on how to build C++ functions and routines on Internet as well, plus acceptable FS's SDK references. All of this should be more than enough for beginners wanting to start writing C++ gauges.

However, for the rest of people that already have basic to medium knowledge in C++ (and I include myself in the medium group), there is a real lack of information on how to deal with advanced GDI+ and DirectX drawing technics in FS, like those referenced by Umberto. OOP in an FS ambient would be a good topic for proper tutorials. Shared cockpit data exchange could be another one.

Tom

PS: @cheangjc, you don't need Simconnect to inspect the value of N1 spool, there is a C++ token var that can be used for this task.
 
OK. With that all said, I'm going to close the thread, and hopefully, a new thread will begin comparing XML to C++ in gauge design. I also hope a much-needed new thread concerning C++ tutorial plans evolves!

Dick
 
Status
Not open for further replies.
Back
Top