Performance Difference Question

[JSkorna]

Hi Guys,

For FS04, if you had a panel with C gauges and a panel with XML gauges, what would be the performance difference between the 2 panels?

Thanks!
Jim

http://www.hifisim.com/banners/hifi-community-sigbanner.jpg
http://www.hifisim.com/

[JanniCash]

I don't have that much experience in coding gauges in C. I tried one or two, but didn't like it. This is not to say that I don't like C (I actually write C code in a Unix environment to make a living ... I am a database core developer), just that I don't like writing FS9 gauges in it.

I do have reasonable experience doing them in XML. It's not published yet, but I took a lot of the Tinmouse graphics by Richard Probst and created my own 737-200 ADV panel entirely in XML. Since the Tinmouse stuff is under the Artistic license and I usually publish all my code under the BSD license, you will see it some day.

That said, I think it doesn't depend as much on the language, as it depends on things common to both. Sure, if your gauge goes away and does extensive number crunching on every single callback, C will always outperform XML. But for your typical "run off the mill" gauge, that just displays a needle in front of a background, or slides one or more number bands under a mask in front of a background, other factors are more important (I think 95% of all my gauges are either one, the other or both of that). I've seen many gauges where the underlying bitmaps aren't in the size that the gauge actually has in the panel. To stick with the simple needle gauge example, take a trivial fuel quantity gauge. The XML or C code just does a lookup for "Fuel Tank Left Main Quantity" and then tells the graphics engine to display the needle bitmap turned around the specified axle to represent x%. Not much (noticeable) difference between C or XML thus far. Both will look at the FS9 internal data, eventually do some trivial math on it and define a "nonlinearity" table that translates percentage values into X,Y coordinate pairs that the center line of the needle should point to for a given value ... interpolated if the exact value is missing in the table. But now the graphics engine has to compute the needle image based on the input bitmap turned Y degrees (representing X% according to the interpolated table), combine that with the background image and then resize the result to the space actually allotted to the gauge in the panel ...

I wasted a few days of my life playing with raytracing and similar ways of keeping computers from being idle. Resizing images for sure is a way to get the most out of your computers share of your electrical bill.

In the above example, the same gauge based on the same bitmaps used in the same way will probably still be faster if implemented in C. But you won't notice the difference in the FPS display. Sure, these differences are cumulative and a loss of cycles here, another there will soon result in a drop in FPS by at least 0.03%. But then again, a simple adjustment of the update frequency of such a gauge (when I fly I usually don't burn fuel at a rate that makes it important to update that needle 18 times per second) will throw all that comparison off.

I'm not really sure what triggered your original question. But if it is just "should I bother learning the other language", then the answer is very simple. Not in this case. I can write bad code in many languages ... I don't consider that a great achievement.


Jan

[xxmikexx]

Hi Jan,

"I'm not really sure what triggered your original question."

I know why Jim asked, because he and I work together at fsOC. We are going to be bringing out an upgrade of the Rich Probst FS9 727 panel, the upgrade to be for FSX, to be released under Rich's unmodified perl Artistic License. The question for our team is whether to do such a rewrite as C-only, XML-only, or to adopt a mixed approach.

I'm not a gauges expert (would you like to become ours?) but I've been playing games with Rich Probst's FS9 727 panel code and I have the distinct impression that a mixed approach to the FSX version would be best for reasons of panel code maintainability.

I'm not as concerned about the relative performance of C versus XML as I had been -- I completely buy your analysis above -- but I'm concerned about the ability to express certain kinds of complex logic in XML in a way that mere mortals would stand a chance of understanding. Here's an example:

I have modified Rich's ASI so that it now maintains five speed bugs instead of two. The speed bugs can be toggled between "displayed" and "hidden" by clicking on a mouse-sensitive invisible box on the ASI itself. When on the ground and made visible the speed bugs go into a takeoff configuration -- rotate, presumed unstick speed and a three-part flap retraction schedule. When in the air the bugs do something similar but with different values -- a flap extension schedule, a recommended touchdown value, and a stall speed indicator.
I plan to extend the logic further so that the rotate and touchdown advisories will be based on some combination of aircraft gross weight and the density altitude. (Oh boy do I wish I knew what I was doing!)

Evidently this logic requires that many variable values persist across gauge refresh cycles, notably the state machine number for deciding what to do under the various scenarios of "was airborne, now on the ground", and so on. There's no question that something as complex as this COULD be written in XML, the question is whether it should.

Honestly, I don't claim to have the answer. None of us at fsOC does, which is part of the reason Jim asked. He is mostly concerned about the relative peformance issues, I am now mostly concerned about the relative code readability issues. What I do know is that XML code looks terribly kludgy to me, and what the world clearly needs is a proper problem-oriented gauge language which would compile down to XML.

Maybe such a tool exists now. I don't know because I'm not a gauges expert and, to date, nobody else on our staff is either. I'm learning, Alex Barrett is learning. But I've been too busy worrying about personnel and business issues to have had time to really research the relative ease/difficulty of doing a complex logic, and Alex has his own independent business to run, Turbine Sound Studios.

So we'd love some advice from you or other people (as well as the participation of you or other people) not only on the performance stuff but also on the issue of code creation and maintenance.

As you said, it is possible to write bad code in any language. The question on the floor really is: "Is it ever possible to write complex good code in XML?"

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

I should mention one other thing which may or may not feed into this discussion -- you will know better than I.

As you probably know, the source code for Daniel Steiner's FSsound dll seems no longer to be available. As an "industry" we have the .H file for the programming interface, and we have the binaries for the .dll, but there is no way to extend Daniel's interface without reverse engineering the whole module, something that is on my to-do list.

Not only that, I have no idea what license FSsound is assumed to be distributed under. This issue alone is sufficient for me to want to do a partial rewrite, so that I will support at a minimum those FSsound calls that Rich makes and be able to distribute the resulting utility source code without any license restrictions. (Please note that fsOC code will be freely redistributable open component freeware when downloaded,even though it will also be distributed as payware when recorded to CD.)

Even apart from licensing issues, is it reasonable to try to attempt to interface to FSsound from within an XML gauge? Even if it is, would it be possible/reasonable to do the FSsound rewrite in XML? My quess is that the answer to each of these questions is "no", but that is admittedly a guess.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Finally, Rich has lost the source code to his 737-200 panel. Do you still have it? If so, would you let us have it too? The sources are supposed to be freely available, including to fsOC, but if nobody has them then the point is moot. I've located a fairly decent freeware decompiler, but all it has been able to produce is structured assembler. I'm a C/assembler programmer so by itself that is not a problem -- except that it would be extremely difficult to reconstruct the "gauge-ness" aspect of the code rather than simply the "C-ness" of the code.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Well ... I've taken enough of your time. fsOC is not your average FS add-on development organization, especially considering our mixed freeware+payware approach to the world. (See the %ware button on our website.) Note that the payware CDs will be $10+s/h aircraft CDs targeted at beginner FS users. The fsOC 727, first for FS9 and then for FSX+FS9, will be our initial aircraft release, with all open components to be freely downloadable from the FlightSim file library, and freely redistributable to other file libraries. This will include FDE values and the sources for our .mdl.

Are you interested in taking the pledge?
Anybody else? We really do need gauge mavens.

(Applies mouth brakes now.)

[xxmikexx]

I don't recall which thread I just found this on but on 28may of either 06 or 07 a gentleman name J Pillborough posted a notice that his program Gaugedes 1.0b1 is available for download from SourceForge. I have downloaded both the source and the binaries for this program, which is an HLL for compilation down to XML.

[taguilo]

Hi Mike,

Regarding your question:

"Is it ever possible to write complex good code in XML?"

I would say that, unless you need to make a sound gauge, a File IO gauge or a ND gauge with GDI+, you SHOULD write the most complex code in XML, because it can't be beaten in terms of portability, development time and easiness of testing.

Maybe the problem is, there ain't many expert FS XML programmers, just because it turns to be difficult for most people to understand RPN; and also professional developers need to write C gauges as to protect their source code.

But, once the structural idea of writing scripts in RPN is learnt, anyone can write good XML code investing little time in comparison with doing that in C.

Only to give you a reference (subjective of course), the ADI project that you described is a very simple matter to code in XML; even the default GPS and GARMIN gauges are long coded but not really complex from an XML advanced pov.

Tom

[xxmikexx]

Hi Tom,

Thanks for the info. We have no intention of keeping anything secret so unless there's a different good reason for doing things in C then we won't do them in C. (With rare exceptions everthing done by fsOC is going to be open components, not just XML code. This includes our current 727 panel which, before the FSX rewrite, is entirely C code.)

I only want us to get things right in a business sense and if XML really is the right way to go then that's what we'll do, especially because if we approach things correctly we'll get both FSX and FS9 support.

Would you like to join us?

Mike McCarthy

Want to be a payware developer? Click the "How To Join" button on the fsOC website, http://www.fsopencomponents.com

[xxmikexx]

Tom,

Sound we are going to do. File I/O we are going to do. Popup windows we are going to do. (!) (I'm a C/assembler programmer with a good knowledge of the Windows API.)

All of these things will have to be in C, yes? But could we trigger the C code from XML?

As for your other remarks, what's an ND gauge and what's GDI+? Truly, I know next to nothing about this stuff.


Mike McCarthy

Want to be a payware developer? Click the "How To Join" button on the fsOC website, http://www.fsopencomponents.com

[JanniCash]

>Hi Jan,
>
>"I'm not really sure what triggered your original
>question."
>
>I know why Jim asked, because he and I work together at fsOC.
>We are going to be bringing out an upgrade of the Rich Probst
>FS9 727 panel, the upgrade to be for FSX, to be released under
>Rich's unmodified perl Artistic License. The question for our
>team is whether to do such a rewrite as C-only, XML-only, or
>to adopt a mixed approach.

Why is everyone so obsessed with Rich's stuff? I mean, I myself am almost done with my own 737-200 ADV panel based on his graphics and my own XML code ... and of course once I'm done it'll be released under his original license with all its source code.

>
>I'm not a gauges expert (would you like to become ours?) but

If I had the time to do so I might, but unfortunately I'll have to pass on this one. However, feel free to ask when you have a specific problem. I'm always up for a challenge.

>I've been playing games with Rich Probst's FS9 727 panel code
>and I have the distinct impression that a mixed approach to
>the FSX version would be best for reasons of panel code
>maintainability.

There are some things that simply can't be done with XML. I just had such a problem when I tried to make the FsPassengers functions like seatbelts, serving drinks etc. available through my panel. The stuff reacts to keys like SHIFT+CTRL+B for the seatbelts, and the only button provided at all is for exactly that. Needless to say that it is a .gau and links into the FsPassengers.dll directly. So what I ended up doing is an invisible C gauge that monitors L:variables and XML gauges on top of those vars. The C code then injects keystrokes into the Windows message queue to invoke the actions. I still hope that the FsPax developer gets in touch with me so we can develop a general L:varable based API for it.

>I have modified Rich's ASI so that it now maintains five speed
>bugs instead of two. The speed bugs can be toggled between
>"displayed" and "hidden" by clicking on a
>mouse-sensitive invisible box on the ASI itself. When on the
>ground and made visible the speed bugs go into a takeoff
>configuration -- rotate, presumed unstick speed and a
>three-part flap retraction schedule. When in the air the bugs
>do something similar but with different values -- a flap
>extension schedule, a recommended touchdown value, and a stall
>speed indicator.
>I plan to extend the logic further so that the rotate and
>touchdown advisories will be based on some combination of
>aircraft gross weight and the density altitude. (Oh boy do I
>wish I knew what I was doing!)

I hear you! Yes, the ASI with all those refspeed bugs was a bitch. It is one of the largest XML files (475 lines) in my collection.

And I agree, doing complicated calculations in XML isn't that easy. I might have an advantage since I still own and use an HP-48GX, so the reverse polish notation of stack oriented math doesn't confuse me.

>
>Evidently this logic requires that many variable values
>persist across gauge refresh cycles, notably the state machine
>number for deciding what to do under the various scenarios of
>"was airborne, now on the ground", and so on.
>There's no question that something as complex as this COULD be
>written in XML, the question is whether it should.

Since I've done that one, it can be done. I'd have to look into the complexity of adding dependency on gross weight and such to it. Sounds interesting.

>So we'd love some advice from you or other people (as well as
>the participation of you or other people) not only on the
>performance stuff but also on the issue of code creation and
>maintenance.

All I can do at this time is to polish up the code I have so far and let you guys have it to get ideas and maybe cut'n'paste one or the other things you like.

>As you probably know, the source code for Daniel Steiner's
>FSsound dll seems no longer to be available. As an
>"industry" we have the .H file for the programming
>interface, and we have the binaries for the .dll, but there is
>no way to extend Daniel's interface without reverse
>engineering the whole module, something that is on my to-do
>list.
>
>Not only that, I have no idea what license FSsound is assumed
>to be distributed under. This issue alone is sufficient for me
>to want to do a partial rewrite, so that I will support at a
>minimum those FSsound calls that Rich makes and be able to
>distribute the resulting utility source code without any
>license restrictions. (Please note that fsOC code will be
>freely redistributable open component freeware when
>downloaded,even though it will also be distributed as payware
>when recorded to CD.)

The readme in my copy of FSSound says Freeware but not Public Domain. And it explicitly states that it may not be included in any commercial product. No way I'd even touch it with a hex editor.

>
>Even apart from licensing issues, is it reasonable to try to
>attempt to interface to FSsound from within an XML gauge?
>Even if it is, would it be possible/reasonable to do the
>FSsound rewrite in XML? My quess is that the answer to each
>of these questions is "no", but that is admittedly a
>guess.

I have pretty successfully used Doug Dawson's DSD XML sound gauge for all my needs. It is freeware (though I don't know if he'd make the sources available) and quite easy to use. It also uses an L:variable interface, so it would be easy enough to use it from XML as well as C and the entire panel would have one central .ini file that maps which .wav files to play for what effect. Can't make it easier for a user to change the cabin "ding" than that.

>
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
>Finally, Rich has lost the source code to his 737-200 panel.
>Do you still have it? If so, would you let us have it too?

I have

b732.040210.snd.zip
b732.041019.air.ffx2.fs2004.zip
b732.050131.panel.short.fs2004.zip
b732.050131.source.zip

Those numbers seem to be packing dates ... uh oh. But it seems to be better than what you've been working off because I found 4 speed bugs in there. I'll upload it all sometime tomorrow to some place and let you know.

>Are you interested in taking the pledge?
>Anybody else? We really do need gauge mavens.

Pick my brain any time you need. That's all I can offer at this time.


Jan

[taguilo]

>Would you like to join us?

Thank you for you offer Mike, but I'm already working on payware projects.

Anyway, who knows? Maybe later I change my mind.. :-)

Tom

EDIT: Regarding your ASI gauge, it is very easy to position the bugs according to TO speeds, or landing configuration, whatever, with different weights, Thrust ratings, etc, just using polinomials or XML 3DTables. Now, a real challenge is to POSITION each one of the bugs just by dragging it with the mouse, even "pushing" those that follows, if any, like you would do in the real AC :-)

[taguilo]

>Tom,
>
>Sound we are going to do. File I/O we are going to do. Popup
>windows we are going to do. (!) (I'm a C/assembler programmer
>with a good knowledge of the Windows API.)
>
>All of these things will have to be in C, yes? But could we
>trigger the C code from XML?
>

Yes you can, there are functions that can be coded in C to receive XML variables to work with, and also you can update those vars and send their results back to XML. See FSX SDK, there are examples there.


>As for your other remarks, what's an ND gauge and what's GDI+?
> Truly, I know next to nothing about this stuff.
>

ND is for Navigation Display, or Moving Map, and GDI+ is a set of advanced functions/routines to handle vector graphics in C++.

Tom

[JanniCash]

>All of these things will have to be in C, yes? But could we
>trigger the C code from XML?

If you look at the 8th post in this thread http://www.fspassengers.com/forum/read.php?f=3&i=5306&t=5306 you'll find a complete, working example of how to interact between XML and C.

The two gauges in that example reimplement the default Baron 58's Battery Master switch. The XML part this time only manages an L:variable, while the C part monitors that and the Flight Simulators battery switch state. If either of them changes, it causes the other one to follow.

Note that I am a professional C coder myself (database core developer) and love C, but I would always start a FS gauge in XML.


Jan

[xxmikexx]

Jan,

Thanks very much for your detailed and informative reply, and Thanks**N where N>100 for agreeing to be a fountain of gauge and panel knowledge and wisdom. I'm sure that we will be grateful many times in the future that you have made this offer.

Now ... I am going to climb up on my pulpit here and do some preaching. I will answer the question you did ask, but after that I’m going to take the opportunity to answer some questions that you did not ask.



Why Is Everybody Obsessed With Rich Department

You must understand that I'm not an FS expert, neither as a user nor as a developer. There may come a time when I will have become one, but that time is certainly not here today. My main concern is with business and with project management -- not with how particular decisions turn out but rather with the need to see that decisions get made timely, and that they get made in the right way so that they will result in good outcomes.

It all started a few months ago before fsOC had been conceived. I am a huge 727 fan but had been disappointed with a certain commercial 727 product offering that most other people probably are well satisfied with. Because of my AirBoss(TM) committments I simply have not had the time to do much pleasure flying during the past few years. When I do it is **** well going to be in 727s, whenever possible. So ... I did a search and came up with the Probst panel, which I had not heard of before.

Mirabile dictu! Hey Presto! Katy bar the door! Get out of town!

Rich's panel was everything I had ever wanted in a 727 panel, and more. It was and is a magnificent piece of work, fully the equal of anything out there in paywareland which, as I learned from Rich as I began to correspond with him, was no accident. That had been his goal, he said, to show the world that marvelous panels need not be the exclusive domain of the payware development houses, that freeware could be even better than payware.

So I'm not obsessed with Rich -- I have a lot of other things to be concerned with -- but I stand absolutely in awe of someone whose skill set is so broad and whose vision is so clear as to be able single handedly to conceive and execute a project of this complexity – and then to be generous enough to make the result available in source form for the benefit of the entire FS community ... which includes both me and fsOC.

So when fsOC talks about rewriting Rich's 727 panel, or his 737 panel, to paraphrase Newton, "If I have seen farther than others it is because I was standing on the shoulders of giants."

In other words, as far as I'm concerned, in that regard it doesn't matter what the rest of us do now or in the future. To paraphrase the USA civil war general Nathaniel Bedford Forrest, Rich got there "fustest with the mostest". Game over. Period, end of subject. It is the panel against which all other 727 panels must be measured, and it is the 2D panel against which all other 2D panels must be measured.

Or so it seems to me as a newcomer to this world of FS nuts-and-bolts. (I’ve been a lightweight FS user for many years but never before have I been involved in the current way.)



Taking Care Of Baby Department

I promised Rich that I would take care of his baby and I'm trying to live up to that promise. Some time after I made the promise the idea of fsOC came to me. The fsOC concept is rooted conversations of mine with a certain elder statesman of this hobby, but my ideas went well beyond these discussions and ended up culminating in the concept of %ware -- of having the same content sometimes be freeware and sometimes be payware, with the developers able to receive royalties in the payware situations.

Rich is not 100% thrilled with the idea that his panel has become payware-in-the-making but he agrees that, under the Distribution Fee provision of the perl Artistic License, fsOC has every right to distribute the panel as part of our planned line of $10+s/h Air Plain aircraft. So ... We have the legal RIGHT to do so -- even Rich agrees with this -- but now the question is whether we SHOULD do it. In other words, isn't fsOC trampling on Rich's moral rights as an author? Let's take a look ...



The Morality Of Air Plain CDs Payware Department

Since fsOC’s budget payware CDs will be aimed exclusively at beginner FS end users, and since these end users will not at first be candidates for the complexities of downloaded freeware, it is my contention that fsOC will be performing a community service in this regard, even if Rich does not agree. These beginner end users are people who, initially, can be reached no other way than through aircraft CDs incorporating aircraft installers. Our own documentation is going to teach these users to be self-sufficient, but when they first come to us they will need to be coddled.

As I have said elsewhere, if these CDs are to be put into the hands of the largest number of end users then distribution will have to be via the usual on-line stores. Those publishers will not carry the CDs unless they are allowed to make a noticeable profit. If the publishers are going to profit then so should the developers – or at least they should be given the opportunity. If the developers are going to profit then the fsOC operating account should receive a cut of the royalty stream (10% of collected royalties) to cover administrative expenses both current and future, and I too should receive a cut (10% of collected royalties) for my marketing efforts and for my business management services.

Where does Rich come in re royalties? They are available to him if he wants them. If he doesn’t want them they will be paid into the fsOC operating account. He is certainly free to receive them and then make charitable donations.

But all of that is beside the point. Given that the fsOC variant of Rich’s panel will be available in open component form just as his original was, does someone like Rich have the moral right to impede the hobby -- to say to these beginner end users “I’m very sorry that you want no part of downloads, which would get you my stuff at no cost to you. I’m also very sorry that your only alternative is to pay $30-$45 for what fsOC is offering to you for $10+s/h. However, even though I am very sorry, that’s life and you are just going to have to put up with it.”

No - - I don’t think that he does have that right, morally speaking. Because if we are to look at the spirit of the law rather than the letter of the law, the spirit behind open source is that the community should benefit through the widest possible distribution of the material - - and an author’s opposition to fsOC %ware would have precisely the opposite effect.

Now a reader’s initial reaction may be “You dirty rat. You’re simply trying to find a way to justify what you had always planned to do to begin with, which is to make people pay for Rich’s panel over his objections.”

No, folks, we’re not making anybody pay for anything. Rich’s original code will continue to be available to all comers, at no cost. The modified code produced by fsOC will continue to be freely available to all comers as zero-cost downloads. The only thing that we’re “making” people pay for is to have the same stuff reach the download-shy people in CD format. Absent our CD offerings these people would be buying nothing, and they would be downloading nothing. Thus are CDs are actually a public service even though they are payware.

Now … It is true that we believe this “lurker” CD market to be actually larger than the market for traditional payware, but that’s beside the point. There is nothing wrong with the profit motive, dear reader. It is, after all, the reason why farmers send their produce to your local grocery store. It is why gasoline is made available to you by your gas station, why your power company makes electricity available to you, and so on … and it is the reason you are able to receive a paycheck from your employer.

So I will argue that fsOC’s approach to life is actually a public service. The traditional freeware community will continue to benefit in the traditional way. No … Wait a minute. … The freeware community will actually be bettered because now freeware distributions will be a) in open component format, and b) not suffer from any arbitrary author-imposed restrictive license agreements.

These payware CDs simply are opening up a new (repeat new) distribution channel, one that cannot be opened by any means other than through the profit motive.

(takes a deep breath and then climbs down from pulpit)

Mike McCarthy

Want to be a payware developer? Click the "How To Join" button on the fsOC website, http://www.fsopencomponents.com

[xxmikexx]

Tom,

Surely you don't expect the general manager to get his hands dirty trying to make the bugs respond to the mouse the way you have just described? :)

I don't know when I'll get to this but quite obviously, the day I do make it happen will be the day when I will have earned the right to pin the Gauge Guy wings to my chest.

Then you and I will stand in front of a mirror and admire each other's wings.

Mike McCarthy

Want to be a payware developer? Click the "How To Join" button on the fsOC website, http://www.fsopencomponents.com

[taguilo]

Mike,

I'm sorry to disappoint you, but I haven't earned any wings nor have plans to do so :-) I also don't expect you to personally code such kind of complexity, not even I've done that so far...

My edit was focused on the fact that FS XML code limits are well beyond many people could think, and the goal in terms of future developments is precisely to give the users advanced elements that are a step forward of the regular FS stuff, almost reaching those limits. Amazed customers usually means good business :-)

Tom

[JanniCash]

Mike,

to clarify, the question about the "obsession with Rich's stuff" was rather rethoric. I know well why I used his Tinmouse panel as a starting point.

And you answered actually a couple of questions I would not have asked in the first place, though others reading this tread might. Rich provided the Tinmouse panel under the artistic license. Since I used those bitmaps and some of the sounds, it is not me to chose the license for my panel any more. Although I could in theory put the code under a different license than the bitmaps. But what kind of mess does that produce for the resulting binaries?

If you research my name a little you will find out that most of my work is published under the BSD license. I have no sleepless nights over people making a buck out of what I publish for free. If you can add enough value so that people pay for things they could get for free otherwise, go for it.


Jan

[xxmikexx]

Thanks Jan,

Our plan is to create not only new panel code but also new gauge and panel artwork, along with new sounds provided by Turbine Sound Studios, who have a general sounds library in addition to engine sounds. When ready this material will be released under the fsOC license and not the Artistic License. However, in the meantime we may very well go to market with the tweaked Probst panel, under the Artistic License as discussed in my previous post. Either way, I'm sure you'll agree that we all owe Rich a big round of applause for showing the world what one determined and highly skilled person can accomplish, and for inspiring people like me to try to match to match his work, which we will never be able to do, at least not for quite some time.

As for value added, you will have to tell me: Our plan is to create aircraft specifically targeted at newcomers to the hobby. We might or might not make changes/additions to your panel code, and the results might or might not constitute real value added in your mind. However, if you will allow me to communicate with you offline, I will show you that our real value added will be at the aircraft level, with the panel being part of that overall picture.

I have revealed some of our marketing game plan in public but I don't want to reveal the rest of it in public. However, since there is now a non-zero probablility that we will end up using your 727-200 panel code instead of rewriting it, I would like to tell you offline all the things we have in mind so that you will be able to assess the value-added issue for yourself. This is important to me because I would not want fsOC to start down the Jan path only to discover later that we had not won your support in a license sense.

By the way, here too we will be doing new artwork and new sounds, and under our open components philosophy these will be available to all comers, including yourself. If we both play our cards correctly, you will end up owning a shared copyright to a brand new panel which will not be dependent in any way on Rich's body of work, except that he will always be seen to have come first, and that the rest of us will simply be standing in his shadow.

If you're agreeable, please write to me as mike@fscomponents.com

Mike McCarthy

Want to be a payware developer? Click the "How To Join" button on the fsOC website, http://www.fsopencomponents.com

[xxmikexx]

Well Tom,

I'm sure that I could master the complexities of RPN thinking, as could several other people I'm working with. A stack is a stack, I've seen them before. (In fact, many years ago I wrote the front end for a compiler, and the algorithms for dealing with arithmetic expressions are not only stack-driven, they are recursive, which adds a whole 'nother layer of complexity.)

Anyway, what I hear you and Jan saying is "Jump right in, the XML water is fine, you just need to adopt a stack-oriented way of looking at the world of FS variables."

I want to thank both of you for having made me a convert from C to XML. I don't yet understand everything you guys have had to say, but at some point I will, and certainly the people I'm working with will.

They have been beating me up about XML for several weeks now. As of this morning I can stop being the last holdout re C. We will confine our usage of C to those cases where it is absolutely necessary.

I do have a question though Everybody keeps writing "C++". Why is an object-oriented approach desirable in the area of gauges? I've certainly done O-O but frankly, I detest it. I find it an obscure way of doing what good programmers do anyway in C or ANSII C.

Again, I'm open minded. If there's a good reason to be objected oriented in the remaining C code then object-oriented we will be, but I would like to see the reasoning, if you're willing to take the time to give it.

Mike McCarthy

Want to be a payware developer? Click the "How To Join" button on the fsOC website, http://www.fsopencomponents.com

[JanniCash]

>Thanks Jan,

>Either way, I'm sure you'll
>agree that we all owe Rich a big round of applause ...

Absolutely.

>As for value added, you will have to tell me:

No, I don't. The market will tell you. :-)

>I have revealed some of our marketing game plan in public but
>I don't want to reveal the rest of it in public. However,
>since there is now a non-zero probablility that we will end up
>using your 727-200 panel code instead of rewriting it, I would
>like to tell you offline all the things we have in mind so
>that you will be able to assess the value-added issue for
>yourself. This is important to me because I would not want
>fsOC to start down the Jan path only to discover later that we
>had not won your support in a license sense.

I agree, we should take this part of the conversation offline. I don't really care much for licenses, as long as people do really understand what they mean and don't complain later if they misunderstood.

>If you're agreeable, please write to me as
>mike@fscomponents.com

Will do.


Jan

[n4gix]

>>All of these things will have to be in C, yes? But could
>we
>>trigger the C code from XML?
>
>If you look at the 8th post in this thread
>http://www.fspassengers.com/forum/read.php?f=3&i=5306&t=5306
>you'll find a complete, working example of how to interact
>between XML and C.

There's no need to even go that far. Right at the top of this very forum is all the information required:

http://www.flightsim.com/dc/dcboard.php?az=show_topic&forum=31&topic_id=233&mesg_id=233&page=

:P

[n4gix]

Frankly, I see no essential difference between your description of how fsOC would sell the compilations as ~$10 CDs and how Redhat (and many others) have taken Linux and wrapped it up within an installer, GUI and a host of other support utilities, all of which are designed to make it (relatively) easier for the newbie to begin using Linux instead of trying to configure it from all the "open source" bits-and-pieces... :9

What the "customer" is actually paying for is the wrapper & ancillary support materials, as well as the media itself and the marketing/distribution/support costs.

-----------------

With regards to the entire XML-vs-C question, were it entirely my decision I would script (I absolutely refuse to refer to XML as "code") nearly all of the display gauges in XML. As Tom and others have mentioned, setting aside the RPN issue, it is a rapid way to produce and debug a gauge in situ, something that is quite impossible to effect with a C gauge.

With three monitors, I can script the XML on the left monitor, have FS running on the center monitor, and have Adobe Photoshop CS v8.0 on the right monitor, which provides me with an optimized workflow environment.

To ease the development of complex RPN "math," ACES has provided a handy utility program with the FSX SDK named "Infix2Postfix.exe" that will allow you to enter the entire calculation in C# style notation, and will then cheerfully spit out the entire mess translated into proper XML syntax. It also works in reverse, taking a complex XML scripted calculation and recasting it to C# notation.

XML is also quite capable of creating elaborate vector drawn gauge elements, although gradients are not currently possible.

-------------------------

The two major shortcomings of XML scripting, as has been mentioned already, are the complete inability to perform file I/O, and no sound support.

However, it is really a fairly trivial task to code a "blackbox" gauge in C that will provide all the file I/O operations, up to and including database searches. In fact, that is precisely the purpose of the gps.dll provided by ACES, which allows the default XML GPS scripts to perform look ups and searches of the native FS GPS databases... ;) With the release of the FSX SDK, ACES has kindly provided working examples of how to code the C interface .dll and the XML scripts by which to access/control it.

Further to the above, the gps.dll also demonstrates quite graphically (pun intended!) that it is possible to have the .dll send back a pre-rendered DIB SECTION bitmap that may be then displayed in the XML scripted gauge. Of course, it also shows how slow that process can often be, with often rather disappointing update rates... :(

Similarly, it is also a trivial task to build a "blackbox sound gauge" as Doug has already done. I used essentially the same method to code a simlar gauge for use in ESDG projects, as we have a fixed library of "stock sounds" that are used by all our gauges, both C and XML. Playing a specific sound requires only a simple command, such as:

1 (>L:XMLClick,enum)
1 (>L:XMLPush,enum)

------------------------

Now, with regards to reverse-engineering FSSound.dll, I have to ask, why bother?

Why not simply code a similar gauge using the DirectSound API? If you're interested in 'compatibility' keep in mind that the "goes inta" syntax is something over which you have full control. What happens internal to the .dll is something about which the user need not concern him/herself!

[JanniCash]

>There's no need to even go that far. Right at the top of this
>very forum is all the information required:
>
>http://www.flightsim.com/dc/dcboard.php?az=show_topic&forum=31&topic_id=233&mesg_id=233&page=
>
>:P

Since my example code also writes the L:variable, I used the method you mentioned in the second post of that very thread. What do you think where I learned this? ;-) I'm not tremendously smart, but smart enough to use "search" and then "read". Sorry, should have given proper credit.

I only pointed to the complete example (which you may add to the above thread if you like) because it was already there and because it is actually a complete example with ready compiled .gau and .cab files that someone can download for trial.


Jan

[n4gix]

>Since my example code also writes the L:variable, I used the
>method you mentioned in the second post of that very thread.
>What do you think where I learned this? ;-) I'm not
>tremendously smart, but smart enough to use "search"
>and then "read". Sorry, should have given proper
>credit.

LOL! Not to worry, Jan! I'm certainly not the sharpest pencil in the box either. I just read and study a LOT and am blessed with the time to indulge myself...

I actually fancy myself as one of those people described by Robert Heinlien in one of his earliest novels: to wit, an "Integrationist."

I'm able to take widely disparate bits of datum and integrate it into a whole, which I then take joy in sharing with others... ;)

[xxmikexx]

Oh my, so much to respond to. Thanks for your very thoughtful post.

Re Red Hat, I think that's a very good analogy. We are specifically targeting the beginner customer, just as I have the impression that they do. (I wouldn't know. I haven't used Linux since before Red Hat came out many years ago.)

Re infix2postfix.exe, another excellent tip. Did you see my post #3 regarding Gaugedes 1.0b1, the HLL-to-XML compiler? Do you know anything about that tool? It's up on SourceForge so I suppose that if it has bugs, or if the author has abandoned it, it might be fixable. On the other hand you're probably going to tell me that Real Programmers Don't Need Tools Like That, and you're probably right, though I haven't seen serious XML with my own eyes yet.

Re file I/O, and sound support, to that I would add support for WinAPI popup windows. When I get a breather I will check into gps.dll as you have suggested.

Re FSsound.dll, I dunno. It seemed like a good idea at the time but you're probably right -- why bother? I have a licensing concern about all this utility code so it may be in fsOC's best interest to build stuff from scratch anyway. I really don't want to get product out there only to have to recall it because MS or Doug developed a problem with what we were doing.

The main reason I chose FSsound as the conceptual model is, that's what Rich Probst's panel is coded to use. But it would be easy enough to change the code in principle. (In practice there's an awful lot of it which is most of why I felt that a plug-compatible replacement would be the way to go.)

However, since we plan to rewrite the panel in XML anyway (all of you guys have convinced me today that this is what should happen), in the rewrite we'll be able to do whatever we want. Prior to that rewrite fsOC absolutely does not have the right to distribute the FSsound.dll binaries so I really have no short term choice but to recreate the small number of FSsound calls that Rich was making -- register a sound file, initiate one-time playback, initiate looping playback, test whether one-time playback is complete, stop playback, unregister the file. I don't have the code in front of me but I think that's what was going on. I haven't worked with DirectSound before but I know DirectX joystick, keyboard and mouse service quite well so I presume that DirectSound will pose no particular difficulties.

Thanks again.

As always, Bill, you 'da man on this stuff. I really appreciate your advice and I hope we'll be able to tap into you. I'm not going to be doing a lot of gauge programming but some of my colleagues may

Mike McCarthy

Want to be a payware developer? Click the "How To Join" button on the fsOC website, http://www.fsopencomponents.com

[xxmikexx]

I would cheat by putting the autothrottle bug setting knob into special V1,V2 and so on modes, allowing "increase" and "decrease" clicks to be used, completely avoiding the need to become SuperProgrammer. :)

Mike McCarthy

Want to be a payware developer? Click the "How To Join" button on the fsOC website, http://www.fsopencomponents.com

[n4gix]

>Re Red Hat, I think that's a very good analogy. We are
>specifically targeting the beginner customer, just as I have
>the impression that they do. (I wouldn't know. I haven't
>used Linux since before Red Hat came out many years ago.)

I've observed you struggling to explain the conceptual outline of fsOC over and over again, apparently without much success. It simply occurred to me that - in general at least - there's no obvious difference between the two marketing/distribution paradigms.

Hence, using the example of the myriad "Linux" payware bundlers at least has the benefit of being an extant, comprehensible and widely accepted scheme.

>Re infix2postfix.exe, another excellent tip. Did you see my
>post #3 regarding Gaugedes 1.0b1, the HLL-to-XML compiler? Do
>you know anything about that tool?

Yes, I saw the reference you made, but haven't a clue whether it would be useful or not. Understand that XML isn't something unique to FS. In fact, ACES' use of XML is somewhat of a "perversion" of the original intent for XML, since its primary purpose is to facilitate the sharing of data across different information systems, particularly via the Internet.

See: http://en.wikipedia.org/wiki/XML for further information.

>The main reason I chose FSsound as the conceptual model is,
>that's what Rich Probst's panel is coded to use. But it would
>be easy enough to change the code in principle. (In practice
>there's an awful lot of it which is most of why I felt that a
>plug-compatible replacement would be the way to go.)

That was precisely my point, Mike. Since your intention is to code a "plug-compatible replacement" it makes absolutely no difference whatsoever what language or API you ultimately choose to use.

As I said (colloquially), the "goes inta" can - and should! - be the same. What this means is that the calls to the module can easily remain the same as is used by FSSound.dll! For example, in Rich's "Dimmer.c" file, the call for a "toggle sound is:"

MFSSoundFilePlay(Toggle1, FALSE);

There is absolutely no reason why you would need to change the input format. The first parameter passed is the "name of the .wav file." The second parameter passed is a boolean to indicate looping TRUE or FALSE.

You could even code alternative input parameters beyond those FSSound used to achive other goals, but by allowing the same format for the input parameters, your "replacement" would truly be "plug-compatible" in every sense of the term.

[xxmikexx]

Hi Bill,

Again, thanks for the Red Hat analogy -- good description model. However, while it is useful in situations such as redistribution of material originally distributed under open licenses such as perl Artistic, it does not address the problem of restrictive developer "don't make money with my stuff" licenses.

That's why, except for the two Probst panels, essentially everything fsOC builds will be built from scratch. We will be sidestepping those restrictive license issues altogether, and perhaps it is this crucial break with the conceptual past combined with the requirement for distributor payment of royalties that is making it difficult for me to explain things and difficult for people to understand things.
People have said before "feel free to make money with my stuff". To my knowledge nobody has ever before added the caveat "... but if you do you must pay us royalties".

While it is possible that not everything fsOC builds will in fact be open component, there aren't going to be any restrictions on the distribution of that work product that does become open component.

Doesn't this provide ample opportunity for pirates to cheat by using fsOC stuff and then not paying royalties? Well, yes, but then those folks had better not show their faces in a big city poolroom ever again, if I may paraphrase a line of dialog from the old movie "The Hustler". Once we're established no online retail store, including eBay, is going to touch product from folks we haven't approved in a negotiated royalties sense.


xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Re the "gozinta" issue, that's what I meant by "plug-compatible" -- no modifications to Rich's source code. If other software needed to use a "new" FSsound it would be necessary to respect the entire interface defined in Daniel's .h file and not just the function calls that Rich uses. That's why I meant by "full plug compatible rewrite", or whatever words I used or implied.

You're effectively asking "Why view it as FSsound at all? If the interface being used in Rich's code is preserved, then what difference does it make what's on the other side of the interface?"
I don't disagree but there's a lot of older <FS2002?> stuff out there that depends on interacting with a .dll named fssound which in turn would have to provide the same set of exported functions (in an interface sense) as Daniel's old module does. Were it not for that issue I would not give a rodent's rear about FSsound other than to thank Daniel for his generous past services to the community.

Is there actually a need or benefit in going beyond what Rich's code needs? That's what I meant by "I dunno". Rich and I discussed one low-priority change having to do with sound panning in outside view mode, but if nobody else needs anything beyond Daniel's FSsound binaries then the point becomes essentially moot. Because what we have now ain't really broke and I don't want to take the time to fix it if nobody else would care.

I had been unaware of Doug Dawson's stuff but again I don't want any licensing headaches so we won't be using Dawson no matter how much functionality it provides.

Mike McCarthy

Want to be a payware developer? Click the "How To Join" button on the fsOC website, http://www.fsopencomponents.com

[n4gix]

It's difficult to communicate ideas using only words...

Why code an entirely new "replacement module?" It's simple really. The OS support that FSSound.dll has been depecrated... Before long, there will not be any support in the OS at all.

By coding a new .dll using the DirectX API, one could then offer any or all of the features DirectSound allows, including advanced 3-dimensional positioning effects, and filters for echo, distortion, reverberation, and other effects.

[xxmikexx]

Thanks Bill, I guess my ignorance is showing.

I thought that DirectSound was part of DirectX. I know DirectX joy/kbd/mse but I certainly am not a DirectX expert. So you're right about that stuff -- why code for something that's about to die.

Now ... Regarding "deprecate" you're about to teach me something else that's new to me. A year ago June, when I moved some code from VC6 to VC8 I got a compiler message along the lines of "blah blah deprecated blah blah", which I suppressed by means of a pragma declaration along the lines of _USE_NO_DEPRECATE_ or some such thing. (The code's not handy so I can't be more specific.)

What the compiler had been complaining about was, as I recall, my exporting a certain function definition. After suppressing the message my code ran fine on XP, and it runs fine on Vista in native Vista mode, so if "deprecate" means "obsolete", what do you suppose was going on?

Please don't hurt me. :)




Mike McCarthy

Want to be a payware developer? Click the "How To Join" button on the fsOC website, http://www.fsopencomponents.com

[n4gix]

In this sense, "depecrate" means "obsolete and scheduled for removal." Even in FS, there are "depecrated" tokens and key_events that will - at some point - be completely removed from the gauges.h file because they are no longer supported by the OS (in this case, the OS being the FS program itself).

DirectSound is a subset of DirectX. Like DX itself, it is subject to frequent revision, and at some point in its evolution certain things will be replaced entirely, making the older features unusable. At that point, the "old calls" will no longer work. Period.

FSSound was born using the now antique Win95 sound API. I'm astonished that it still works at all!

[WarpD]

>Thanks Bill, I guess my ignorance is showing.
>
>I thought that DirectSound was part of DirectX. I know
>DirectX joy/kbd/mse but I certainly am not a DirectX expert.
>So you're right about that stuff -- why code for something
>that's about to die.
>
>Now ... Regarding "deprecate" you're about to teach
>me something else that's new to me. A year ago June, when I
>moved some code from VC6 to VC8 I got a compiler message along
>the lines of "blah blah deprecated blah blah", which
>I suppressed by means of a pragma declaration along the lines
>of _USE_NO_DEPRECATE_ or some such thing. (The code's not
>handy so I can't be more specific.)
>
>What the compiler had been complaining about was, as I recall,
>my exporting a certain function definition. After suppressing
>the message my code ran fine on XP, and it runs fine on Vista
>in native Vista mode, so if "deprecate" means
>"obsolete", what do you suppose was going on?
>
>Please don't hurt me. :)
>
>
>
>
>Mike McCarthy
>
>Want to be a payware developer? Click the "How To
>Join" button on the fsOC website,
>http://www.fsopencomponents.com

When you encounter that warning regarding deprication, it means in a future OS release the function you're calling won't exist any longer and it's time for you to switch to the newer ones.

It is not wise to ignore the messages, because sooner or later all your code will be "eliminated" by the updated OS.