"Binary Coded Decimal"?

[taguilo 33]

>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.>I see you completely missed the point of the tale. Please reread it, and you will notice I am not precisely talking of C++ as a useless way to code gauges...>>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...>Good. It use to happen sometimes, that people working on a given platform/project reach the same conclusion at almost the same time. That's part of human history.>>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.>Well, at least you're being honest now, and less arrogant to me, recognizing that in fact you don't LIKE XML. It's reasonable that one wouldn't like a given platform to work on, because of many circumstances that in this case you've pretty well explained, although it doesn't give one the right to disqualify it entirely as I think you did before. There were talented programmers in FS team that actually thought of XML as a valid alternative, in an environment that is per se very demanding in terms of overall performance. I wouldn't dare myself to think of them as "idiots", seriously (see the tale's irony?)>>>>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.>In software development, productivity is directly related to the context in which an entire project is going to be developed. Too many variables are involved, not only the decision to use one, two or many programming languages because of its own coding/compiling/debugging advantages.>I'm not saying you can't debug XML code or mixed code, it's>just slower.Again it's not a matter of speed but, as you stated above, overall productivity >Wrong. I am using C++ -though I'm far for declaring myself an>expert->>That's an issue of C++. No, that's an issue of me; I've started to deep on C++ only few months ago.>>C++ requires more dedication. This is true indeed.>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.I also agree with you that maybe not a truly C++ code -in terms of OOP,STL, etc is really needed for most of the common code found in gauges. In the end, one can go as far as FS interface allows to go; there are people that may have broken this -like JeanLuc or maybe you as well- but I think they are the exception.>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. >In FS9, it is enough to send a simple "command" -included in a gauge- to reload the panel and see instantly the changes. It cannot be done so fast in C++. It's a fact. However, in FSX it's true that you need to reload the aircraft and besides the gauges init to starting values which might be rather inconvenient; so not much advantage of XML here I guess.>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.>Actually in some cases you DO need to restart FS; that's when you're working on a system's DLL instead of individual .gau files. Almost every respected commercial developer is placing much of his code into those DLLs that are "linked" to FS via DLL.XML file. This would be my case also. >>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. >I have to agree here. >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.>Yes, it's true that one has to get the source compile ok, after then everything is going to work well, in most cases. At this point, I would say it's easier to let a C++ compiler find glitches than doing XML manual "debug".>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.>>Yes, the cost/benefit formula is obvious, even for freeware projects.And I think this is maybe the source of our main disagreement: I believe most gauge projects would have a better cost/benefit if developed within an integrated XML+C++ platform, and you believe that it would only be possible using C++ code exclusively. As we are talking of productivity, shall depend on the particular context each of us is working on.>>>>What I'm planning to do is build very complex systems>>Well, that's might seems an easy one but, you are planning, I>think I have a couple of real world released products to>show.What I'm planning,-already started actually- is related to the XML+C++ platform, indeed I've done other works exclusively in XML,some quite complex as well. In that case, you'd have to pay for using them, same as I'd have to pay for using yours - I guess we're both on the same side here. >>>that performs asfast as desired>>I 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.I for one couldn't care more on how the user "feels" the simulator is performing when using my panel. Mathematical/statistical performance could be extraordinary in terms of code efficiency but almost useless to the average simmer running FS with plenty of hunger addons he's not using at all, or with MS Messenger/Outlook left open and consuming valuable resources.>>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+)>I agree, but would like to add that fast and slow are very subjective terms in FS vocabulary, because the whole thing depends on so many different interacting areas that focusing only on one of them -ie gauges- could be putting so many effort in an intend to optimize something unoptimizable in the whole perspective.>>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...>Well, was not so obvious to me on the previous posts. I saw your way of making statements rather arrogant; probably you are very experieced/talented in C++ (and/or other) language, -I don't know but I guess you are- so my effort was to bring the discussion into more constructive terms. I apologize for my own rudeness if there was any.>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.>Maybe you're right and the future goes that way, even then XML would still be needed...>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...>I never put in doubt the qualifying characteristics of C++ as a standadard in entertainment developments. I just sated that, in FS world, properly-coded XML solutions should deserve to be considered a serious alternative in some of panels' development projects.Tom

[dragonflightdesign 98]

Hi Umberto>"Fast development/testing" cycle it's NOT just how much time>it will take to restart FSX. It's more about debugging options>at your disposal, and Visual Studio can offer far more>debugging options than anything possible with XML. Agreed - apart from one thing :). If I try and launch FS9 or FSX from within Visual Studio (6a, 2003 or 2005) to debug a gauge, the FS refuses to start until I have detached the debugger. How are you getting around this problem?-Dai

[WarpD 824]

>Hi Umberto>>>"Fast development/testing" cycle it's NOT just how much time>>it will take to restart FSX. It's more about debugging>options>>at your disposal, and Visual Studio can offer far more>>debugging options than anything possible with XML. >>Agreed - apart from one thing :). If I try and launch FS9 or>FSX from within Visual Studio (6a, 2003 or 2005) to debug a>gauge, the FS refuses to start until I have detached the>debugger. How are you getting around this problem?>>-DaiIf FSX is refusing to start... you have something really odd going on. FS9 has that CD check code in it, which prevents a debugger from starting it up. However FSX has no such code and should start up without complaint.

[dragonflightdesign 98]

>>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)>{>>}>Watch for the catch Bill; don't create more than one event handler per multigauge because otherwise the compiler will throw a complete fit. Didn't I write about this? Or maybe I have written about this but not released it yet... gah! I normally create a subgauge that does nothing except handle key events and I always place the event handler before the update routine to be safe.-Dai

[n4gix 4,947]

>Watch for the catch Bill; don't create more than one event>handler per multigauge because otherwise the compiler will>throw a complete fit. Didn't I write about this? Or maybe I>have written about this but not released it yet... gah!Yes, you did write about in in Rev23 as I've just renewed my acquaintance with that section... ;)Happy New Year, Dai!

[virtuali 4,419]

>Hi Umberto>Agreed - apart from one thing :). If I try and launch FS9 or>FSX from within Visual Studio (6a, 2003 or 2005) to debug a>gauge, the FS refuses to start until I have detached the>debugger. How are you getting around this problem?Hello Dai (it has been a long time...)Yes, that's quite normal.I usually do like this:- I launch FS separately, not from inside VS, with the startup airplane being one that doesn't load my gauge.- I just compile the gauge without launching FS, but with breakpoints sets. They will show up as empty red circles, to signal the gauge code is still not active in the debugger- I attach the debugger to FSX.EXE- Load the airplane with my gauge, breakpoints will become solid red, and debugging will now work.- When I finish my debugging session, I detach the debugger, and select another airplane. FS keeps running in the background- VS it's now back into editing code mode, so I can make my corrections, recompile and start again. Just be careful that, if you hit the Stop button in the debugger, you will force quite FS, forcing you to launch it again. To finish the debuggin sesssion, you should instead select a different airplane and detach the debugger, so FS will continue running.

[dragonflightdesign 98]

Hi UmbertoMany thanks for the info - I'll get it written into the next version of sd2gau. If nothing goes wrong it's quite possible that you and I may find ourselves in the same room again sometime around mid-summer. I look forward to that!-Dai