Sign in to follow this  
Guest Ron Freimuth

Variable assignment and initialization

Recommended Posts

Hello,In doing a search I found the following topic very helpful:http://forums.avsim.net/dcboard.php?az=sho...ing_type=searchHowever, the .xdr and .dtd that comes with the FS2004 SDK does not allow this. Is there some conforming way to initialize variables?The Pike tutorial at FS2X.com is fairly instructive, but doesn't really go far enough. Arne Bartel's 2002 XML gauge document is useful, but mainly focuses on RPN (God I wish MS would use infix) and not on how to make and use L Vars.Thanks,J-

Share this post


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

Hi,What else would you like to know about LVars appart from that described in Nick's tutorials and other posts in this forum?Regards,Tom

Share this post


Link to post
Share on other sites

Hi Tom,I understand Lvars and their use. What I am looking for is a syntax which allows me to declare and initialize my LVar variables upfront.Some have suggested this sort of approach: 52(>L:Test, number)This works, but the DTD/XDR that comes with the SDK (which I am using to validate the gauge and to enable Intellisense when using VS 2005's XML editor) doesn't like that.Often, a programmer wishes to declare variables at the top of a source file and I am trying to mimick that. I see many examples where this works well "in line" but I want to be able to declare several variables up front.J-

Share this post


Link to post
Share on other sites

>I understand Lvars and their use. What I am looking for is a>syntax which allows me to declare and initialize my LVar>variables upfront.There is no need to declare LVars in XML; they all default to 0 when referenced for first time. >>Some have suggested this sort of approach:>> > > 52(&-gt-;L:Test, number)> > >>This works, but the DTD/XDR that comes with the SDK (which I>am using to validate the gauge and to enable Intellisense when>using VS 2005's XML editor) doesn't like that.Maybe using ">" instead of "&-gt-;" gives the solution.(Note:"&-gt-;" typo ex-profeso for this message) >>Often, a programmer wishes to declare variables at the top of>a source file and I am trying to mimick that. I see many>examples where this works well "in line" but I want to be able>to declare several variables up front.>If you want to do so, at the top of the gauge you may use: 0 (>LVar1,unit) nn (>LVar2,unit) etc etcTom

Share this post


Link to post
Share on other sites

Hi Tom, could you explain a little further please? Is it just a shorter form of code to assign fresh values to the variables?cheers,nick

Share this post


Link to post
Share on other sites

AFAIK, it seems to be MORE that simply a place to set up the various variable's initial values, because it's clear from the G500 code example that the section is read each cycle.There's "dynamic code" in the section of the G500.

Share this post


Link to post
Share on other sites

Nick, is a tag, like ,, etc. Basically it is a stack holder; it means any kind of operation that uses the stack can be done here. As Jan stated, it brings the same functionality as within an , though the stack is handled slightly different (more details below) It can be placed anywhere in the structureFor example:-At the top of the gauge file after -Between two structures-After a structure-etc.A can contain only one . If more than one is found, only the last one will be considered by FS.It has its own flags: "Frequency"; "Hidden" is well known. is a flag that controls whether data will be updated when the gauge is hidden. operates on its own stack, not shared by Elements and other gauge's structures. It can be a good replacement of data-only elements.Hope this was clear enough. Tom

Share this post


Link to post
Share on other sites

Tom,Thanks for that explaination. I'm curious about ; Does that determine how other Element's tags are interpreted? For example, it's known that the condition controls the DISPLAY of data, but doesn't prevent calculations from taking place despite the being hidden. Does prevent that?Thanks,--Jon

Share this post


Link to post
Share on other sites

>Tom,>>Thanks for that explaination. I'm curious about >; I had tried around blocks and found I could only have one block.>Does that determine how other Element's tags are>interpreted? For example, it's known that the >condition controls the DISPLAY of data, but doesn't prevent>calculations from taking place despite the being>hidden. Does prevent that?>--Jon I think I know how to see how much CPU is used by gauges. C or XML. I noted that if I Pause FS9 and minimize the window, the Windows Task Monitor may still show a high load for FS9. The gauges continue to run even with FS Paused. At least, if 'Pause' isn't used in some way to stop execution. "(A:Sim Disabled,bool)" didn't appear to be equivalent to "Pause". It would certainly be useful if currently invisible displays didn't take all that CPU power. I expect the visual parts don't load the CPU when not seen, but the other coding does. Ron

Share this post


Link to post
Share on other sites

> I had tried around >blocks and found I could only have one >block.Right, as Tom said. Also, and this is the killer for me, there is a definite limit to the number of 'if's one can perform within an element. I know my code breaks when I try combining all my code into a single block. It will quite literally crash FS9 if there are too many.Even though there are only perhaps 10 top-level "if" structures, the subordinate "if"s are also somehow contributing to the limit.> I think I know how to see how much CPU is used by gauges. >C or XML. I noted that if I Pause FS9 and minimize the>window, the Windows Task Monitor may still show a high load>for FS9. The gauges continue to run even with FS Paused. At>least, if 'Pause' isn't used in some way to stop execution.>> "(A:Sim Disabled,bool)" didn't appear to be equivalent to>"Pause". Pausing the sim does have an effect on frame rates - they go up, but not nearly as much as they should, considering the sim is PAUSED!> It would certainly be useful if currently invisible>displays didn't take all that CPU power. I expect the visual>parts don't load the CPU when not seen, but the other coding>does. Indeed, and that's why I'm interested in what is doing. Right now I store the condition in a register which I check later in the structure to prevent calculations from taking place: For example:(L:Condition, bool) (L:Condition2, bool) and s0l0 if{ a bunch of trig }Since there is generally a lot of trig in many of my elements, I find it prudent to check the condition of prior to making the calculations. This wouldn't be necessary if simply worked correctly in the first place. I could be wrong, but I can't come up with any reason why it would be beneficial to execute calculations in an invisible block!The down side of doing all those checks, is they too use CPU. If you've got several hundred blocks, they add up. --Jon

Share this post


Link to post
Share on other sites

OK just to answer my own question, I've confirmed that Update Hidden="No" does in fact prevent calculations from being carried out behind tags! Good news! I am seeing large improvements in performance, and it will go up even more once I remove all my visibility check cludges.EX:1 With (or omitted), Test Var gets set to 1 despite being set to 0.0pseudo...%(1 (>L:Test Var, enum)Test Var = 1EX:2 With , and Test Var set to 5 Test Var remains 1 with still set to 0.0pseudo...%(5 (>L:Test Var, enum)Test Var = 1EX:3 With set back to "Yes", Test Var gets set to 5, proving that 0pseudo...%(5 (>L:Test Var, enum)Test Var = 5--Jon

Share this post


Link to post
Share on other sites

Ron,>The gauges continue to run even with FS Paused. At>least, if 'Pause' isn't used in some way to stop execution.Actually nothing stops running when sim is paused EXCEPT that sim vars (A/E/P) are NOT updated. But (L/G) vars indeed are.Every piece of code is still executed, so there is not really a big save in CPU cycles. Tom

Share this post


Link to post
Share on other sites

Jon,>Right, as Tom said. Also, and this is the killer for me,>there is a definite limit to the number of 'if's one can>perform within an element. I know my code>breaks when I try combining all my> code into a single> block. It will quite literally crash FS9 if>there are too many.>Even though there are only perhaps 10 top-level>"if" structures, the subordinate "if"s>are also somehow contributing to the limit."if{" operators are jumps whithin the stack. It seems reasonable that there should be a limit of its memory pointers, just considering there is only 30 value holders in each FS stack. However, I think much of these "if" jumps could be avoided using boolean math. I try to use as less "if/els" as possible, though have to be honest and say sometimes I can hardly understand my own code!! :-)Tom

Share this post


Link to post
Share on other sites

Jon,Unfortunately, I didin't get the same results as you got regarding the "Hidden" flag.My Lvars still update even with Hidden="No" and 0 ; placed wherever, inside ,,, etc, Actually what I found is:Hidden="No" REDUCES the update frequency of the structures to near a 10 % of its original frequency, when THE GAUGE is not visible (the panel that contains it is hidden)But the code inside the is still executed at its original frequency.For example, for the default frequency of 18 cycles/sec, it seems that it is reduced to a little more than 1 cycle/sec.For a frequency=6 it seems to go down to 0.5 cycle/sec.I did those test some time ago. I think they deserve a new round :-)Tom

Share this post


Link to post
Share on other sites

>Ron,>>The gauges continue to run even with FS Paused. At>>least, if 'Pause' isn't used in some way to stop execution.>Actually nothing stops running when sim is paused EXCEPT that>sim vars (A/E/P) are NOT updated. But (L/G) vars indeed are.>Every piece of code is still executed, so there is not really>a big save in CPU cycles. >Tom If Paused and Minimized, Task Manager shows CPU load may drop quite low. Unless there is a lot of gauge code in the sim. So, what's that (A:Sim Disabled,bool) related to? I guess one could look at the FS time, and if it isn't changing, the sim is paused. One could then jump around some or all code blocks with an if{ block. Since I Strobe my XML calculation blocks, I could change the Strobe rate dynamically if I wanted to. But, other than stopping the Strobes when Paused, I don't see much reason to do that. OTOH, if one is calculating a lot of navigation trig stuff, then there are probably times the rate can be decreased. And, if XML gauges tend to slow down the FPS or add pauses, then one might slow down the less important XML blocks so the important ones can continue to run as fast as necessary. That suggests a user adjustment so he can Tailor the slow down for his PC speed. Ron

Share this post


Link to post
Share on other sites

Tom,Interesting. I wonder if Update Hidden has a different effect in the absence if an block. Using FRAPS I can see large performance gains, but I'm not seeing any slowdown in the execution of structures. For example I plot lots of symbology in HSI and radar pages, and even if there was a slowdown it would certainly be noticeable (particularly if it was 90%!). I still get smooth rotations and displayed variables are updating just as they had before. The only difference is there's much less CPU being utilized.Again, my results were that there was no execution within a 0 and all visible elements still performed at what seemed like normal levels. I guess the next step is to place a filter in a block and see what the frequency is.--Jon

Share this post


Link to post
Share on other sites

>So, what's that (A:Sim Disabled,bool) related to?I don't know. I always read it as 0, even when using the PAUSE_TOGGLE event.>I guess one could look at the FS time, and if it isn't>changing, the sim is paused. One could then jump around some>or all code blocks with an if{ block.Yes, I agree with this option. FS time stops when Paused. Interesting is, the WHOLE sim execution stops when a menu is selected.>Since I Strobe my XML calculation blocks, I could change>the Strobe rate dynamically if I wanted to. But, other than>stopping the Strobes when Paused, I don't see much reason to>do that. OTOH, if one is calculating a lot of navigation>trig stuff, then there are probably times the rate can be>decreased. I also use strobes rather than FS time and found the problem that strobes still run when sim is paused. Still didn't make code to handle pauses. That would be one of my next tasks.>And, if XML gauges tend to slow down the FPS or add>pauses, I don't think this applies to XML gauges only but also C/C++ ones. What really eats CPU time and FPS is OUTPUT , everything that is shown on the screen. On a maximixed FS window, CPU percent use nears or is 100 %. When the sim is paused, there is no percetible decrease of CPU usage (maybe 1 % or less) but the memory usange in bytes remains unchanged . This last one seems logic, as there is no sim vars actualization.But, when FS is minimized (no output to screen), CPU usage drops to a 15-17 %, for my 757 with 130 XML custom gauges, to 1 % for the Piper Cub and 45 % for LevelD 767. I think the difference is pure data and structural code actualization, which indeed happens because Lvars still update at their set frequencies .Tom

Share this post


Link to post
Share on other sites

Jon,>Interesting. I wonder if Update Hidden has a different effect in >the absence if an block. "Hidden" is a flag. I've found no different effect when usingor code>For example I plot lots of symbology in HSI and radar pages, and >even if there was a slowdown it would certainly be noticeable > (particularly if it was 90%!). I still get smooth rotations and >displayed variables are updating just as they had before.Maybe I've done a different test. You could try this:-In a gauge that is placed on a subpanel which can be displayed/hidden (Like the GPS), add an structure. -Then, add an (L:VarTest,enum) ++ (>L:VarTest,enum)-In a gauge placed on the main fs panel (always visible), add a test string like %(L:VarTest,enum)%!5.3f!-Then toggle the subpanel display and see how it affects the update's rate of the Lvar.-Change in the subpanel's gauge with (L:VarTest,enum) ++ (>L:VarTest,enum)-Then remove the that refered to (L:VarTest,enum) previously.-Then toggle the subpanel display and see the difference.>I guess the next step is to place a filter in a block and see what >the frequency is.I'd be glad to know the result of your tests :-)Tom

Share this post


Link to post
Share on other sites

>>So, what's that (A:Sim Disabled,bool) related to?>I don't know. I always read it as 0, even when using the>PAUSE_TOGGLE event. A whole window of A:Var,bool variables displayed as 1 or 0 would help. >>I guess one could look at the FS time, and if it isn't>>changing, the sim is paused. >Yes, I agree with this option. FS time stops when Paused.>Interesting is, the WHOLE sim execution stops when a menu is>selected. It even stops for a moment when a mouse button is pressed and the cursor is on the View screen.>>Since I Strobe my XML calculation blocks, I could change>>the Strobe rate dynamically if I wanted to. ...>I also use strobes rather than FS time and found the problem>that strobes still run when sim is paused. Still didn't make>code to handle pauses. That would be one of my next tasks. I display all my strobes as 0110100 at the top of one or more Test Display windows. That way I could see if they are working. At times, some heaver FS load on the CPU makes the Count (also displayed) slow down a bit. Let me know when you find a good way to detect Pause. Since my XML stuff is running all the time, the Integrators 'wind up' when Paused. That would put a jerk in the SPD controller. I also saw a jerk in one of my Pitch controllers after un-pausing. Regardless, I need to think a bit more about initializing some of the Integrators I use. It appears others aren't critical.>>And, if XML gauges tend to slow down the FPS or add>>pauses, ....>What really eats CPU time and FPS is OUTPUT , everything that>is shown on the screen. On a maximized FS window, CPU percent>use nears or is 100 %. When the sim is paused, there is no>percetible decrease of CPU usage (maybe 1 % or less) but the>But, when FS is minimized (no output to screen), CPU usage>drops to a 15-17 %, for my 757 with 130 XML custom gauges, to>1 % for the Piper Cub and 45 % for LevelD 767. I think the>difference is pure data and structural code actualization,>which indeed happens because Lvars still update at their set>frequencies .>Tom Right, I've checked the effect of reducing the View. I also found my simple XML data windows slowed down frame rate at times when stretched out to a large size. C gauges appear to also run all the time. Often a change results in a momentary drop in FPS, then it increases back to the normal rate. Probably due to moving code and data back into active RAM and L1/L2 caches from pagefile.sys or storage space in RAM that FS likely sets up. Pause makes no difference unless the Sim is minimized. CPU usage then appears to be a function of all the gauges running in the BG. In fact, if the gauges don't take many cycles the CPU load may be quite low with FS flying on autopilot when minimized. There is no View to keep updating. That iFly C gauge takes forever to load. Gosh, it's 48 MB! The next largest .gau file in my gauges is under 10 MB. I think it takes a lot of CPU all the time. Clearly, there should be a way to slow or stop code when it isn't needed. Your and Jon's (conflicting) experiments with look promising, though I'm not sure that it would fit in my XML stuff. Ron

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

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

Create an account

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

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this