Sign in to follow this  
mgh

Borland C++ Builder

Recommended Posts

I've just posted a short tutorial in the file library explaining how to start using Borland C++Builder4 Professional to create a C gauge. The file name is:BorlandCPPBuilder-V1.0.zipBorland C++Builder4 Professional is the only version of this compiler I have but I would hope the advice given should be applicable to other versions - especially later ones.BTW I hope there are other Borland users here - or am I out on a limb?

Share this post


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

That was very kind of you! I'm sure there are probably more than a few who'll find it useful. ;)

Share this post


Link to post
Share on other sites

Thanks! I'm sure that'll be very useful. I've only worked in XML so far, but have several college credits in C++, so maybe your tutorial will be the thing that puts me back into that "mode." One thing: Can someone briefly highlight the specific advantages to actually programming in C++, vs. the -based structure of XML??? I know that in general a programming language like C++ would offer much wider flexibility, virtually limitless probably, but what kinds of flightsim gauge things, specifically, have people done in C/C++ that they could not have done in XML? I do this for fun only, have only done 1 gauge actually, and would like to know if the initial reinvestment of time/learning on my part would be justified, given my rather... um... "casual" nature. (Heheh. ;-) There's only been one instance where I've wanted to do something in XML that I couldn't get to work (I would've had to basically put a long trigonometric statement in the nonlinearity portion of a statement), and I think it could've been done pretty easily in C++, but that has been the only instance.... Comments, anyone, about the advantages/disadvantages of one vs. the other?

Share this post


Link to post
Share on other sites

Here's my 2 cents worth on the subject: A large part of my decision is whether the gauge will be freeware or payware. If payware is the target, then C is my only option, since I must have a way to protect my intellectual property. Another major factor is the degree of complexity of the gauge. More complex gauges are best coded in C, because of the possibility of using classes, defines and other labor and resources saving techniques. Two other points should be considered as well. If the gauge requires file input or output, then C is the only option. Likewise if the gauge requires sound effects. Although there are some C/XML workarounds for sounds (such as Doug Dawson's free utility program), anything more than "simple sound effects" can become a programmatic nightmare... If freeware is the target use, then it is more a matter of determining which method provides the easiest route for building. Obviously, assuming one is at least minimally compent in building gauges in C is a prerequisite... OTOH, anyone with a competency using Notepad.exe and some ability to do mental gymnastics wrestling with RPN can build XML gauges. In general terms then: 1) analog gauges are (mostly) quicker to build, debug and complete in XML. 2) glass gauges are often better built and perform better if coded in C++ combined with GDI or GDI+ 3) ALL XML gauges are "parsed & translated" into pure C code by the sim at runtime. Therefore XML "glass gauges" are "translated" into simple GDI drawing code, and suffer from the same limitations as any gauge coded with GDI: no alpha blending, no linear gradients, and poor 'resizing' when undocked. In addition, this process of "uncabbing, parsing, translating, and executing" of XML gauges makes for extremely slow loading times, and the increased overhead can lead to really horrible performance issues

Share this post


Link to post
Share on other sites

>>Comments, anyone, about the advantages/disadvantages of one>vs. the other? I would strongly suggest you take a look at XML at the W3 consortium website for a clearer understanding of XML, its strengths and its limitations.To truely get a sense of why FS is using XML now, you need to understand what XML is, and how it relates to (near)future development and (near)future distributed computing paradigms. Emphasis on distributed. The strengths of C and C++ (recall that C and C++ are not the same language) are not in question, but their abilities in the approaching paradigm will be seriously challenged by emerging XML technologies.As an arbitrary starting point:http://www.w3.org/TR/xbc-use-cases/#x3dtransThen start digging.CheersShad

Share this post


Link to post
Share on other sites

I'm sure you know but it isn't necessary to "cab" XML gauges.

Share this post


Link to post
Share on other sites

I've just uploaded a revised version of my tutorial as:BorlandCPPBuilder-V1.1.zipIt corrects a bug relating to Borland's use of underscores preceding function names which can conflict with FS's requirements.

Share this post


Link to post
Share on other sites

Shad,I suppose the danger here is the fact that we use the words "XML" and programming the same sentence. There is a sort of scripting language embedded within the XML tags for an XML gauge, but XML (yes, I know you know this - this is just a public caution) is merely a structuring mechanism with the ability for metadata and data quality controls built-in.I truly regret that ALL the options for gauge/panel making remain truly arcane. In many ways, the advent of XML gauges was a blessing, but the RPN really ruins the "ease of use" for XML gauges. As we do a tug of war between machine and natural language, the use of RPN is a step backwards in favor of how the machine works and thinks. Perhaps my mental acuity just isn't that of some others, but having to screw around with the RPN really blows it for me.On the other hand, the C gauge programming really feels like a black art too. However, if you've been formally trained in programming, you can get the picture on that stuff eventually. As Bill L. said above, the real power and heavy lifting for gauge programming still requires C.As I wrote in the FSX preview forum, I would really love to see something FAR easier for gauge programming - something more structured than the C-based SDK gauge programming and something towards the ease-of-use of XML without the damned RPN.J-

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