Sign in to follow this  
Guest darrenecm

C++ basic info for MSFS

Recommended Posts

I feel like an idiot asking this...I know loops and if's, variables and such but what the heck is a pelement header and a pelement list?Rather than hand me an answer, is there any sort of guide that starts with the idea that the reader can already write a console app in C++ but has no clue about graphics, the windows GUI, etc. etc.?That's where I'm at. Rudimentary C++ I understand... but what the heck is a pelement anyway?Vorlin

Share this post


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

It is 'typical' in C that a pointer variable start with the obligatory 'p'.. thus pelement is a pointer variable that points to an element. An element is something declared in the gauges.h file.It's really simple... just think of it this way:Everything in C is reduced to either a number or a pointer. All variables lie within that realm, and exactly what you're looking at is interpreted based on that.char a; <-- number, seriously!!!char* a; <-- pointer (to a number)pelement element; <-- pointer to a type of structure called an elementC has no actual 'knowledge' that letters and numbers are physically different to the human mind, it treats them as one and the same when referencing them. You can add numbers to characters and characters to numbers.Pointers are just big ugly numbers that represent a physical address in memory.Then only difference in all of this is the name. In other words, whatever name is given a variable is the best 'clue' as to what the variable represents to the developer.

Share this post


Link to post
Share on other sites

Vorlin, as your basic question has been answered far better than I ever could: Have you already downloaded and devoured, ingested and digested Dai Griffith'ssd2gau17.zip? if now go get it NOW!!! :)

Share this post


Link to post
Share on other sites

I have read Dai's work twice now... maybe with twelve or twenty more times through it will begin to digest! lolI understand that pelement headers and pelement lists are pointers to elements that are headers or lists.... what I'm wondering is what is their purpose in a gauge the way that they're being implemented according to the SDK?It seems that they denote the order of things, but they're doing so in a way that isn't exactly intuitive. It may be a good coding practice and counter-intuitive at the same time... just like RPN.I'm just trying to get "the lay of the land".Thanks for any and all insight! The above cleared up what they are exactly... now I'm just trying to get a handle on how they're implemented when it comes to gauges. I may be making it tougher than it is... if they simply order things, as I suspect, why on earth did they change from the sort of master list in a single place that the SDK briefly refers to as being used in the past?Vorlin.

Share this post


Link to post
Share on other sites

To which pelements do you refer? There are two usages for them. One as a parameter in a callback function, simply a back reference to the drawing element it is used with. If you don't use callback functions (like using <Value> elements without RPN), you don't need them. The other purpose is to be the "glue" between the different draw elements of a gauge, like a needle has to be glued (or attached) to background. Since it is possible to use more then one "child" element the "glue" is realized by these arrays of pelements. In XML the nesting of <Element>'s describe the structure of the instrument, in C you have formally independent elements, which are structured by the pelement arrays between them. And on a final note, the C structure is up-side-down compared to the XML structure. The background is near the bottom of the C-file, the top element near the top.

Share this post


Link to post
Share on other sites

Short version: The glue answer hit the spot. Drawing elements in C are still above my C skill level at this point but I was able to understand your explaination because I understand drawing in XML.Thanks Arne!Vorlin

Share this post


Link to post
Share on other sites

Once you got the formalism, C and XML aren't so different in their principles. Since the goals are the same (twirl and shift bitmaps around to create the illusion of a real instrument), it is no wonder that the means aren't too much different. XML is somewhat more basic and also more flexible in my opinion (C knows it's MAKE_ macroes, where each does a specific job, XML elements can be simple to complicated with several <Shift>'s,<Select>'s,<Rotate>'s, etc.).

Share this post


Link to post
Share on other sites

>Once you got the formalism, C and XML aren't so different in>their principles. Since the goals are the same (twirl and>shift bitmaps around to create the illusion of a real>instrument), it is no wonder that the means aren't too much>different. XML is somewhat more basic and also more flexible>in my opinion (C knows it's MAKE_ macroes, where each does a>specific job, XML elements can be simple to complicated with>several 's,'s,'s,>etc.). I personally find XML to be cumbersome in coding design. It intentionally obfuscates what is actually happening. I also find XML gauges rather easy to 'steal'. Not so with C. ;)When you toss in GDI+ rendering, combined with the fact they're much, much harder to steal... C gauges tend to win in my book.

Share this post


Link to post
Share on other sites

"When you toss in GDI+ rendering, combined with the fact they're much, much harder to steal... C gauges tend to win in my book."Absolutely... but you have to have the skills to use those tools. I'm still working on that part!Scott / Vorlin

Share this post


Link to post
Share on other sites

>"When you toss in GDI+ rendering, combined with the fact>they're much, much harder to steal... C gauges tend to win in>my book.">>Absolutely... but you have to have the skills to use those>tools. I'm still working on that part!Well, if it's any comfort at all, consider that I only began a few short years ago myself... ;)

Share this post


Link to post
Share on other sites

>>"When you toss in GDI+ rendering, combined with the fact>>they're much, much harder to steal... C gauges tend to win>in>>my book.">>>>Absolutely... but you have to have the skills to use those>>tools. I'm still working on that part!>>Well, if it's any comfort at all, consider that I only began a>few short years ago myself... ;)He's still trying to order the skills online... *ducks for cover!*

Share this post


Link to post
Share on other sites

<-- Raises both eyebrows!b'tch slapped by Father Bill? Rut roh!Well, then again I was warned by someone that he can be a bit "cantankerous" at times! lolOh Bill, Re: the email. I got 16 bit 444 to work as a happy medium... no more CTD's.I actually solved the bus issue due to an archived post of yours from last year. Remember this?***************Title: Re: FSDS2 conditional display and FS9 variablesPost by n4gix on Jan 3rd, 2005, 3:38pm ---------------------------------------------------------------------Actually, in practice, the two techniques are still identical in the end...You see, the _L.bmp is only providing a "light source" behind the gauges, but the actual "light" is supplied by the gauge itself...(etc. etc.)***************Now let's see... the semicolon goes at the beginning of every line in C right?Scott / Vorlin

Share this post


Link to post
Share on other sites

>>Then only difference in all of this is the name. In other>words, whatever name is given a variable is the best 'clue' as>to what the variable represents to the developer.Wow, I appreciate how difficult it is to break down a complex issue and make it so even I can understand it. I applaud you.If I may add: And effective and verbose in-line commenting will save your butt many a time (not to mention being bookmarkable/highlightable in most IDE's/editors).CheersShad

Share this post


Link to post
Share on other sites

>Well, then again I was warned by someone that he can be a bit>"cantankerous" at times! lolNot at all! CURMUNDGEONLY is the correct adjective! ;)>Oh Bill, Re: the email. I got 16 bit 444 to work as a happy>medium... no more CTD's.Great!>I actually solved the bus issue due to an archived post of>yours from last year. Remember this?>>***************>Title: Re: FSDS2 conditional display and FS9 variables>Post by n4gix on Jan 3rd, 2005, 3:38pm >--------------------------------------------------------------------->Actually, in practice, the two techniques are still identical>in the end...Yep... The easiest way for anyone to visualize this is to consider how an LCD monitor works. Unless there's a "light source" behind the LCD, the screen will remain active, but DARK......by using various shades of gray, along with gradients, etc., one may produce any sort of backlighting effect they desire. ;)

Share this post


Link to post
Share on other sites

LOLYer not old enough yet for curmudgeonly.

Share this post


Link to post
Share on other sites

>LOL>>Yer not old enough yet for curmudgeonly.Actually, he is.No one really knows this... but he was the 13th disciple of Christ. Never mentioned in the Bible because of that fateful mistake of convincing ******* to wear shorts one day. Talk about Middle Eastern fashion faux paux!!!(ya know I lubs ya Bill! ;) )

Share this post


Link to post
Share on other sites

>>>>Then only difference in all of this is the name. In other>>words, whatever name is given a variable is the best 'clue'>as>>to what the variable represents to the developer.>>Wow, I appreciate how difficult it is to break down a complex>issue and make it so even I can understand it. I applaud you.>>If I may add: And effective and verbose in-line commenting>will save your butt many a time (not to mention being>bookmarkable/highlightable in most IDE's/editors).>>Cheers>ShadI learned many years ago that 'professional' knowledge is simply knowing the 'secrets' to a job. Most of the time those 'secrets' are extremely simple in reality, yet obfuscated by professional lingo to confuse the mere 'commoner'. ;)

Share this post


Link to post
Share on other sites

>>>>Then only difference in all of this is the name. In other>>words, whatever name is given a variable is the best 'clue'>as>>to what the variable represents to the developer.>>Wow, I appreciate how difficult it is to break down a complex>issue and make it so even I can understand it. I applaud you.>>If I may add: And effective and verbose in-line commenting>will save your butt many a time (not to mention being>bookmarkable/highlightable in most IDE's/editors).>>Cheers>ShadSo very true.If only the original gauges.h SDK file followed such sensible advice on using 'in-line' comments. I find myself regularly delving deep into the gauges.h file in order to figure out how to get at the data I need and to get my gauge DLL to 'produce' code How *I* see fit rather than how all those obscure macros see fit :)Thanks to the sterling work of Arne Bartels, Dai Griffiths and others on the fs9gauges.h alternative header file, things are bit more fathomable, but there are still large tracts of 'commentless' and cryptic parts of the header file in evidence because that's how it was originally written.Comments cost nothing in terms of program execution so I'm not sure why anyone writing code that is plainly going to be seen and used by others should not be sufficiently documented by comments.For example, I'm pouring through lots of OpenGL sample code from all over the Internet in order to get my own OpenGL drawing tricks within a gauge to the level where hardware acceleration can be easily utilised. As such, my C/C++ files are awash with green-hued slashes and explanatory text wherever I'm using concepts I've derived from these sources. As Shad points out, such verbose commentary will always save your own butt when you find yourself returning to your code at a later date to update it with new tricks.One thing I like about Visual Studio 2005 IDE is that if you mark sections of your code using a comment like the following://TODO Need to optimise this blitcopy routinethe IDE notices the TODO text and places that comment line in a helpful Task list section for you to refer to and finish off at a later date. Double clicking on the Task entries in the listing will then whiz you right on over to that section of your code so you can make your edits. I'm not sure if this same feature is in the Visual Studio .NET 2003 IDE but I find it invaluable in keeping track of my code development.That blitcopy reference reminds me. I've read posts in other forums about blitcopying sometimes being required during drawing gauges, particularly those who are bypassing the use of clunky rotating bitmaps and are insstead drawing directly to a gauge surface.I find all the C++ and GDI/GDI+ memory blitcopy routines somewhat inefficient because they all do their copying on a byte-by-byte basis. Modern CPUs are at their fastest and most efficient when dealing with 32-bits (some even 64-bits), not bytes.So I'm wondering if it's not better to 'roll your own' blitcopy routine. This would involve the use of pointers with one pointing at the start of your image source in memory and the other pointing at the destination surface. You then start copying the data from one to the other using a loop that copies entire 32-bit chunks rather than bytes as you increment the pointers.You do have to be comfortable with using 'pointer arithmetic' techniques as you increment these pointers in the loop, but it's not as bad as it sounds :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this