"Binary Coded Decimal"?

[taguilo 33]

The problem with XML is that people in general know very little about the real power of its scripting system, and others like you seem to know nothing at all. MS gave us a good example with the GPS, but in fact that is not more than a starting point, things could go way more complex than that, once you have spent a reasonable time working on this platform.But I can't blame you here, because you are an expert in C++ and therefore it seems fair to me that you want to stay with pure C++ code. In fact, in your case I would do the same for sure. However, after being working for a long time with XML "gauges", I recently moved to a C++ dll development where I'm still learning to code custom classes, use String libraries (seems you like them) and define complex structures to interact with very specialized XML scripts. And I'm quite amazed for the results so far in terms of performance and simplicity.That's the reason I stated my opinion on the subject, it's because I have done the proper work to know something about. I'm not saying I know the whole truth here. You sound cathegoric in your statements, despite those are nothing more than you own opinion as well.I'm still entitled to mine's :-)Tom

[n4gix 4,947]

I'll add my two cents worth to the discussion from the viewpoint of one who not only codes the gauge system, but also builds the 3d models to work with said gauge system.Given that all 3d parts in a virtual cockpit are animated via embedded XML scripts (I will not give it the dignity of referring to it as "code"), it is quite obvious that the task of synchronizing the 3d parts with their 2d gauge system counterparts is much easier if both use the common XML paradigm.Thus far however, I've had to use a rather clumsy system to synchronize the 3d XML scripted animations/mouse-rectangles with entirely C++ based gauge systems. While it works fairly well, it's a total PITA to get working.I think that for future projects I'm going to explore the possibility of using XML for provide the human interface for even the 2d gauge presentations, and build the gauge system (logic, etc) as a dll...

[virtuali 4,421]

>The problem with XML is that people in general know very>little about the real power of its scripting system, and>others like you seem to know nothing at all.Sorry, I know perfectly well what XML can do or can't do.The XML "power", is in fact its ability to create, very shortly, undreadable and unmaintainable code with something little bit more complex than the average, leading to something as ugly as...>MS gave us a good example with the GPSThe GPS...Yes, it's a complex instrument. But you missed entirely my point: I wasn't saying that you can't create complex instruments in XML. You surely can, but that would result in such a coding orror.BTW, the MS GPS it's not entirely XML. In fact, XML is there just for the user interface to call the gps.dll and THERE lies the real "beef" of the instrument (just call the number C: calls and what they do). Check what the gps.dll functions do, and that's all C++, XML alone wouldn't have been able to efficently do the whole gps.>However, after being working for a long time with XML>"gauges", I recently moved to a C++ dll development where I'm>still learning to code custom classes, use String libraries>(seems you like them) and define complex structures to>interact with very specialized XML scripts. Once you start doing C++ seriously, you'll realize that you can rewrite all your specialized XML scripts very easily, and probably wondering why you spent so much time on it in the first place.

[virtuali 4,421]

...

[virtuali 4,421]

>Given that all 3d parts in a virtual cockpit are animated via>embedded XML scripts (I will not give it the dignity of>referring to it as "code"), it is quite obvious that the task>of synchronizing the 3d parts with their 2d gauge system>counterparts is much easier if both use the common XML>paradigm.It's no so obvious. In fact, during the developement of my last 3 airplane projects (the Cloud9 MB339, the Cloud9 Phantom and the MS F/A-18 ), I found that more I "stripped" out the XML animation script, moving more and more logic from that script into C++, the project became faster and easier to maintain.We ended up with the F/A-18 using an modeldef.xml that is more tags than code, and XML expressions are so basic, because everything else is done in C++, and XML acts just as a very weak glue.>Thus far however, I've had to use a rather clumsy system to>synchronize the 3d XML scripted animations/mouse-rectangles>with entirely C++ based gauge systems. While it works fairly>well, it's a total PITA to get working.I think I know what you are referring to, and that probably is the polling of a L: var to handle custom VC events. FSX SDK has a very powerful and elegant replacement technique for this, allowing to define and catch custom events, that behave exactly like standard ones.Have a look at the Acceleration modeldef.xml given with the SDK, you'll find all our part definitions there. Have a look for the K: events without a name, only a number. Those are custom events, that you can "catch" in C++ with a Callback keyboard handler. Yes, XtoMdl knows about custom events.>I think that for future projects I'm going to explore the>possibility of using XML for provide the human interface for>even the 2d gauge presentations, and build the gauge system>(logic, etc) as a dll...Sorry to disagree, but I find C++ far better EVEN for human interfaces. C++, OOP and UI/Human Interface are DESIGNED to work together!The problem is, you can't simply write in some sort of basic C, you have to use C++ to the fullest, with full OOP and Patterns, then you can start grasping its power. I stronly suggest you this book, it's the Sacred Bible of OOP:http://www.amazon.com/Design-Patterns-Obje...l/dp/0201633612For example, the MFD interface paradigm of the F/A-18, has been implemented using the Command Pattern. http://en.wikipedia.org/wiki/Command_patternIt's a very well known technique that allows to easily link objects that do actions. Perfect for UI elements, buttons, etc.

[taguilo 33]

>>The XML "power", is in fact its ability to create, very>shortly, undreadable and unmaintainable code with something>little bit more complex than the average, leading to something>as ugly as...>>How come XML code is perfectly readable, maintainable and "pretty" to me? Because I've been investigating, developing and testing this platform during the last three or more years. So it's perfectly normal for me to feel comfortable within this environment, as I know it very well. And I can understand the frustration people that haven't gone that far could feel. >The GPS...>>Yes, it's a complex instrument. But you missed entirely my>point: I wasn't saying that you can't create complex>instruments in XML. You surely can, but that would result in>such a coding orror.>Well, I kinda agree here, GPS code isn't the most friendly and clean code I've seen, even it tends to be rather intimidating for novices.But I still think it's a good starting point, and the door key for those who want to go beyond the basics. >BTW, the MS GPS it's not entirely XML. In fact, XML is there>just for the user interface to call the gps.dll and THERE lies>the real "beef" of the instrument (just call the number C:>calls and what they do). Check what the gps.dll functions do,>and that's all C++, XML alone wouldn't have been able to>efficently do the whole gps.>>Now I see your confusion, so let me clarify a bit:XML alone can do NOTHING. XML gauges don't exists as such. XML variables are not "real" variables and XML events are not "real" events as well. The whole XML platform is nothing more than an interface cleverly developed by FS team to construct C++ "gauges" at aircraft init, instead of having to construct them from C# macros in dll (aka .gau) files. That't all about. So the real power of XML system is precisely the possibility to interact directly with C++ classes and functions in such a mode that all its ex-profeso limitations can be easily overcomed.Again, as FS team gave us the GPS example showing the door to the real XML power, now they gave us the CabinComfort example that shows an useful way to complement XML's easiness of its property/scripting system with the strong, almost unlimited power of C++. I am convinced there goes the future in gauge development.>>Once you start doing C++ seriously, you'll realize that you>can rewrite all your specialized XML scripts very easily, and>probably wondering why you spent so much time on it in the>first place.>>It's exactly the other way: I'll try to code even more specialized scripts, which will save me tons of time in development process, but doing C++ serious homework as well in those specific areas it is absolutely necessary. Tom

[virtuali 4,421]

>How come XML code is perfectly readable, maintainable and>"pretty" to me?One can get accustomed to anything.That doesn't change the fact that is still ugly and, more importantly, unmantainable.>Now I see your confusion, so let me clarify a bit:>XML alone can do NOTHING. Sorry, there's no "confusion" of any sort. The fact is that with an XML/C++ hybrid approach, and that XML alone can't do much, simply results in the following:- You have to learn something new, that is not really a programming language- Since XML alone doesn't cut it, you have to learn C++ *anyway*- You have to add the gotchas of the hybrid approach- You will be able to exploit the much more powerful dev environment that Visual Studio offers, only for half of your code.>So the real power of XML system is precisely the possibility>to interact directly with C++ classes and functions in such a>mode that all its ex-profeso limitations can be easily>overcomed.The only reason why you would use XML is if you don't know C++ at all. If you have to use C++ anyway, for all the above reasons, you'll be much better doing everything in C++I already explained in my previous message to Bill, why C++ is better for UI as well. C++/OOP is THE language of choice for GUI programming, expecially with the proper patterns. Of course, using C++ as if it was just a glorified C, would not get anything of this. That's why many mistakenly think that with C++ they have a lot of wheels to reinvent, they are missing years of language developement and experiences in things like STL, Templates, Patterns.>It's exactly the other way: I'll try to code even more>specialized scripts, which will save me tons of time in>development process, but doing C++ serious homework as well in>those specific areas it is absolutely necessary. Well, of course you are entirely free to choose to work your way backwards, if you are more comfortable with it.Stating that XML will "save you tons of development time", only means you are slower in C++, not that XML is faster.

[n4gix 4,947]

>We ended up with the F/A-18 using an modeldef.xml that is more>tags than code, and XML expressions are so basic, because>everything else is done in C++, and XML acts just as a very>weak glue.>I think I know what you are referring to, and that probably is>the polling of a L: var to handle custom VC events. Yes, that is precisely the problem. With the constant stream of updates passing back-and-forth, it is inefficient. I'll definitely make it a point to install and examine the Acceleration SDK's modeldef.xml file and take a very close look... :)The only "code" in my modeldef.xml is animation and mouse rectangles. All logic is contained in the C gauge: switch_cover50 (L:SwitchCover,number) 50 * 200HandOpen/Close Cover(L:SwitchCover,number) ! (>L:SwitchCover,number)

[taguilo 33]

>>How come XML code is perfectly readable, maintainable and>>"pretty" to me?>>One can get accustomed to anything.>>That doesn't change the fact that is still ugly and, more>importantly, unmantainable.>A little tale:"Once upon a time an idiot guy belonging to a workgroup in partnership with the most successful software company in history woke up and thought 'Ah, today I will invent a new way to code gauges,something evil and useless that will make the arrogant pundits talk nonsense for many years...' "Now seriously, is it so much difficult to be at least *a bit* humble when one has to speak of things that don't know with authority? -btw it's no me who's claiming to have the truth here, despite both of us are giving our own and equal valid opinion.>>Sorry, there's no "confusion" of any sort. The fact is that>with an XML/C++ hybrid approach, and that XML alone can't do>much, simply results in the following:>>- You have to learn something new, that is not really a>programming language >>- Since XML alone doesn't cut it, you have to learn C++>*anyway*>>- You have to add the gotchas of the hybrid approach>>- You will be able to exploit the much more powerful dev>environment that Visual Studio offers, only for half of your>code.>So what's the problem with all of the above? I'm already riding on that road and I'm not feeling sick, overwhelmed or whatever because of that decision. >>>The only reason why you would use XML is if you don't know C++>at all. If you have to use C++ anyway, for all the above>reasons, you'll be much better doing everything in C++Wrong. I am using C++ -though I'm far for declaring myself an expert- and I see its pros, which are too many, and cons, which are few. And of course I'm also using XML syntax, which have many cons and a few pros. As I'm fond of boolean logic, I can see what gives the joint of the two statements :-)>>Stating that XML will "save you tons of development time",>only means you are slower in C++, not that XML is faster.>>Well, I'm not planning to win a race to anyone. What I'm planning to do is build very complex systems, that performs as fast as desired, being at the same time friendly to develop but with enough power to handle the edged areas. And,based on my own experience and my recent works,IN MY OPINION, XML + C++ is the platform to play with. But I'm not saying I won't change my mind in the future if, during the development, things don't result as expected. I hope this statement could bring you some comfort :-)You can stick to C++ forever, it won't make you any harm for sure.Good byeTom

[mgh 89]

The three generally accepted main properties of C++ for OOP are:Encapsulation - combining a data structure with the finctions dedicated to manipulating the data by creating classesInheritance - building new derived classes that inherit the data and functions for previoiusly defined classesPolymorphism - giving an action one name or symbol that is shared up and down a class hierarchy with each class in the hierarachy representing the action in away approprite to itself.

[n4gix 4,947]

>FSX SDK has a very powerful and elegant replacement technique>for this, allowing to define and catch custom events, that>behave exactly like standard ones.>>Have a look at the Acceleration modeldef.xml given with the>SDK, you'll find all our part definitions there. Have a look>for the K: events without a name, only a number. Those are>custom events, that you can "catch" in C++ with a Callback>keyboard handler. Yes, XtoMdl knows about custom events.Okay, I've seen in the Acceleration modeldef.xml what you're referring to, but......I have no clue how to code a callback keyboard handler. Have you any prototype for an example? I'm assuming also that you are sending the "update" for the L:var from that same callback as well, so the 3d part will receive it's animation control.

[virtuali 4,421]

>A little tale:>"Once upon a time an idiot guy belonging to a workgroup in>partnership with the most successful software company in>history woke up and thought 'Ah, today I will invent a new way>to code gauges,something evil and useless that will make the>arrogant pundits talk nonsense for many years...' "ROTFL, apart for the fact that similar "useless" ways of writing gauges is used by many of the most successfull gauges/airplane addons developers as well, you might try to be a little bit more careful with your stories, at least not trying to use the term "humble" in the same discussion, when you posted the above nonsense first.An very enlightening comment was made to me by JeanLuc of RealityXP at the Seattle Devcon, unquestionably one of the best gauges vendors out there (talk about "idiots programming gauges in useless ways"...), after we discussed our approach to gauges. He's of course a strong C++ supporter, BTW.We found our approach of using a C++ framework that wraps everything in the gauge SDK and does even a lot more in addition, was very similar in concept.And of course, we agreed that, after many years of flight sim programming experience, that choice was the obvious one, and it was reassuring that two developers, living at opposite sides of the world, that never worked together, reached basically the same results...>Now seriously, is it so much difficult to be at least *a bit*>humble when one has to speak of things that don't know with>authority? You are making again the wrong assumption that I'm speaking of XML without knowing it. That's exactly because I KNOW it, that I can speak of it. The fact that YOU like it and don't feel slowed down by it, doesn't automatically means that I can't "speak with authority", because I DON'T like it.>btw it's no me who's claiming to have the truth>here, despite both of us are giving our own and equal valid>opinion.Exactly, See above. >So what's the problem with all of the above? I'm already>riding on that road and I'm not feeling sick, overwhelmed or>whatever because of that decision.A very simple example: when you have to debug something written in mixed code, you have to constantly juggle between the Visual Studio debugger for things written in C++, and relying on printing on screen or put some kind of diagnose code in XML for things written in XML.This alone is a major showstopper in productivity.I'm not saying you can't debug XML code or mixed code, it's just slower.>Wrong. I am using C++ -though I'm far for declaring myself an>expert- That's an issue of C++. It requires much more dedication than other programming languages. You can probably easily mix VB and Python and Perl and C# and switch between all four with reasonable effort. C++ requires more dedication. Of course, I repeat again, to *really* say you use C++, I mean the whole thing: OOP, STL, Iterators, Templates, etc. Possibly Patterns, but that's more a programming style, not really related to C++, although they are of course very much suited to it. Otherwise, it's just C compiled with a C++ compiler.>and I see its pros, which are too many, and cons, which are>few. And of course I'm also using XML syntax, which have many>cons and a few pros. As I'm fond of boolean logic, I can see>what gives the joint of the two statements :-)Except with the fact that the few XML pros can be done quite easily with the same effort in C++, while the many C++ pros can't be replicated in XML in any way.Even the most popular XML pro, that is faster to develop because you can immediately see changes, it's not entirely true. You have to at least restart the airplane. Many mistakenly think that you have to restart FS to recompile and debug a C++ gauge. Not true, you simply need to select a different airplane without the affected gague, re-compile, attach the debugger to FS process, launch the airplane, debug, detach the debugger, edit source code.All without leaving Visual Studio or FS. Not that slower than XML, basically the same, on a machine with plenty of ram, but of course way more powerful, given the superior VS debug abilities.But anyway, the very concept of *wanting* to "immediately see changes", is VERY amateurish. The whole point of C++ and OOP is to being able to write code that requires much more planning and very little debugging. The idea is to have errors and bugs chatched BEFORE running the program, using strong typing and all the various language features, to have the compiler already realizing something is wrong or might be wrong at runtime, not compiling. Or, having the compiler solving the most common source of bugs: non-initialized variables, by using constructors with initialization lists, default values, etc.The general idea is that, with C++, it's usually more difficult to have the program getting compiled without errors or warnings BUT, once it compiles, it usually WORKS, doing what is supposed to do. If it still doesn't, it wouldn't usually crash (like C), but it means that something wrong with the basic implementation, something that a debugger wouldn't help with anyway.This is called "A-bug programming". It's of course quite difficult to achieve, because we are all humans and we tend to do mistakes, and C++ is not a fully-pure-OOP language, becasue, being compatibile with C, still has some weak points (the void* pointer, for example, is a "cheat" against the strong typing nature of C++). But nevertheless is a good objective we should strive for.>Well, I'm not planning to win a race to anyone. It's not a question of winning against anyone. You have to "win" against the cost/benefit ratio, that makes the difference between a commercially successful product, and one that doesn't recover its cost due to too much time spent developing it, regardless of how well received it might be with users. At least, if you want to go commercial. If you are making freeware, instead, everything is good.>What I'm planning to do is build very complex systemsWell, that's might seems an easy one but, you are planning, I think I have a couple of real world released products to show.>that performs asfast as desiredI can profile my C++ code using a performance analyzer and I can tell you, for example, how many microseconds it takes to, for example, draw one of the 4 F/A-18 glass gauges when it's on, let's say, HSI mode, compared to RDR mode. Or, how many microseonds it takes to draw an AI target on the radar. Are you able to do that in XML ? Of course not, you can only hope for the best. Without having a chance to do profiling, you cant' even speak about performances, other than generically saying "it feels ok", but sorry, serious performace analysis it's a whole separate subject in itself, and a big one, in real-time/entertainment software developement.You'd be surprised how many interesting things are discovered when profiling: what everybody thinks is fast (because it looks "clean and simple") is instead slower, what everybody thinks is slow, is instead faster, because of the intricacies of which instructions enjoy H/W accell and how much (expecially in GDI or GDI+)>And,based on my own experience and my recent works,IN MY>OPINION, XML + C++ is the platform to play with.Fact that everything discussed here it's always in the opinion of the poster, is saying the obvious...>But I'm not saying I won't change my mind in the future if,>during the development, things don't result as expected. I>hope this statement could bring you some comfort :-)Never been in need of a comfort statement. I already know that, since you are saying yourself that you *are* using C++ anyway, what will happen over the time is that, the more you'll beccome accustomed to C++, the more code you'll move away from XML to C++, ending up, eventually, in the same situation I'm suggesting: using XML just as a "weak link" between the VC model and C++, with XML only passing 3d click events to C++ when they happen (using custom events) and XML only receiving L: variables fully calculated in C++, passing back to the 3D model, and that's it. All XML "code" basically reduced to one-liners.>You can stick to C++ forever, it won't make you any harm for>sure.Well, at least I'm in good company. Apart from some of the best flight sim gauges programmers, that's "just" the rest of the whole entertainment developers community out there, where C++ it's the only recognized standard...

[virtuali 4,421]

>The only "code" in my modeldef.xml is animation and>mouse rectangles. All logic is contained in the C gauge:Very good, that's almost exactly like the approach I'm suggesting, you are only missing the custom events step.>...I have no clue how to code a callback keyboard handler.>Have you any prototype for an example?void MyEventHandler( ID32 evt, UINT32 evdata, PVOID userdata ){ switch( evt ) { case 0x11000: // my first custom event break; case 0x11001: // my second custom event break; case 0x11002: // my third custom event break; case KEY_AP_MASTER: // the user has fired up the standard AP toggle break }}You just need to call register_key_event_handler() passing the name of your handler at start, usually in your module_init() routine, and of course unregister_key_event_handler() during module_deinit().When ANY event, custom or not (see the example), is happening, your handler will be called with the event code as the evt parameter. Custom events starts at 0x11000, they don't have a "name", but XtoMdl is smart enough to recognize hexadecimal codes and let you compile that.>you are sending the "update" for the L:var from that same>callback as well, so the 3d part will receive it's animation>control.Yes, of course. When you set an L: variable from C++, using the set_named_variable_value() call (of course, you have to register that named variable at start), the VC animated part will move accordingly to your animation tags. That's all your two ways code...

[n4gix 4,947]

Thanks, Umberto. I read and re-read the Acceleration SDK, but it just wasn't sinking in...I'm assuming that this:void MyEventHandler( ID32 evt, UINT32 evdata, PVOID userdata ){}may be placed either before or after this:void FSAPI PRE_gaugecall(PGAUGEHDR pgauge, int service_id, UINT32 extra_data){}Oh so! You are defining the hex events in MyEventHandler rather than in the gauges.h file as the SDK suggests... ;)const int EVENT_BUTTON_PUSH = 0x11000; //THIRD_PARTY_EVENT_ID_MIN While the SDKs are certainly a big improvement over the FSX RTM & SP1a versions, there's still too much ambiguity remaining...Thanks again!

[virtuali 4,421]

>I'm assuming that this:>>void MyEventHandler( ID32 evt, UINT32 evdata, PVOID userdata>)>{>>}>>may be placed either before or after this:>>void FSAPI PRE_gaugecall(PGAUGEHDR pgauge, int service_id,>UINT32 extra_data)>{>>}The keyboard handler definition itself, should be placed as a function call at the main gauge level. You will probably have just the prototype for it somewhere in your main .H file, and the function body at some place in you main gauge. Meaning, not inside a sub-gauge.Depending on your general gauge structure, you will have to place the call to *register* the handler at any place that is executed only once when starting the airplane. I use module_init() (you have to break down the GAUGE_TABLE_BEGIN macro to have access to it), but as long as that code is executed only once when starting the airplane, it's fine.unregistering it's the same, place the call to unregister the handler in a place that it's executed only once, when unloading the airplane. I use module_deinit(), of course...>Oh so! You are defining the hex events in MyEventHandler>rather than in the gauges.h file as the SDK suggests... ;)I wouldn't touch the official gauges.h file ever. Much better to have your own include files, if needed. Since the hexadecimal events need to have a meaningful name only inside the keyboard handler, you can define those in any .H include file that the .CPP file were the keyboard handler resides IS including, so it can acccess to those definitions.regards,