Sign in to follow this  
Guest sphing

Gauge refresh rates for XML

Recommended Posts

Hi,I have heard that the gauge refresh rate for XML is 18 times per second. Can I force this to change to 1 or 2 times per second? (i.e. the flap setting indicator ...does it really need to be refreshed 18 times per second.)I would assume that being able to reduce specific gauge refresh rates will improve overall FS performance and FPS. Is this true?I remember once seeing an XML tag, located at the header of the gauge file, that appeared to control the gauges refresh rate.Please explain this functionality.Thanks,John

Share this post


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

If the overall FPS performance is noticeably influenced by the XML gauge refresh rate, depends a bit on the complexity and number of gauges in your panel.But here are the results from a testgauge I made:The update frequency determines the interval at which the gauge is refreshed:Line absent, * = 0 or greater than 9: 0.055 sec1: 1.00 sec2: 0.50 sec3: 0.33 sec4: 0.22 sec5: 0.17 sec6: 0.17 sec7: 0.11 sec8: 0.11 sec9: 0.11 secCheers, Rob

Share this post


Link to post
Share on other sites

I have not had a problem with FPS yet. However, my project is going to have a lot of gauges, all in XML. I have noticed that some freeware panels downloaded from the net, that use XML gauges, can have upwards of 700 individual gauge bmp's. That's a lot.I'm working on a DC-9 (see atttachment) and it's working out to be quite large. (I have several other sub-panels for the entire cockpit - not shown in the attachment) I am concerned that as I'm nearing it's completion it will be an FPS hogger. I want to know my options for recapturing some performance back once I begin seeing that happen. (..assuming I don't want to start cutting back on my gauges right away.)Is there any other staticial data on XML gauges and performance that people can share?Thanks,Johnhttp://forums.avsim.net/user_files/46147.jpg

Share this post


Link to post
Share on other sites

""Is there any other staticial data on XML gauges and performance that people can share?""Not that I know of.But I should be too worried if I were you.The aircraft I know of that has an all-XML panel (150+ gauges) doesn't give any noticeable FPS drop, and those gauges don't even use the Updaterate at all (so they run at 55 msec)Rob

Share this post


Link to post
Share on other sites

Hi,Had that discussion with Karl Petterson here in the forum.He seems to be using a lot of "quit's" in his code, maybe helpful?I now have in my 767-300 over 1000 xml gauges, many rather complicated, without any noticeable effect on fps compared with the default baron and 747-400.So don't worry and keep adding!Jan"Procul Negotiis"

Share this post


Link to post
Share on other sites

From the C421B experience, I can only say that if the project is heavy, keep the system simulations as simple as possible; don't try to simulate extreme situations. Most people won't recognize the effort put into it anyway, but all will notice the sluggishness.Use default builtin variables where possible, instead of trying to enhance greatly by putting in loads of special code. I.e. the radar altimeter is wrong, but sufficient for "normal" use.If systems simulations are crucial, build them into "limiter functions" that prevents them on running continously - eating all those needed frames. Nest them as best as possible, such as:Limiter1: Once every second. Limiter2: Once every 5 seconds. Limiter3: Once every 30 seconds. Limiter4: Once every 5 minutes.With limiter I mean simply to check against a time modulo. Every second, limiter1 function is done once. If this second falls within limiter3 this is also performed. That way you don't need two routines checking against time. Naturally sometimes this is desireable but try to minimize it.For every element,select,value tagset, "frames" are dropped. In the C421B (FS2002, not released) what I experienced wasn't that the frame performance dropped, but that FS didn't manage to update blurry textures or update the terrain mesh. This problem didn't become apparent until I started doing "long-haul" testflights into distant areas. At "home base" these problems didn't show up :(You can fix *most* of MSFS problems, but it *will* come at a cost. Simulating various "custom systems"; from cabin pressure, via automatic failure generation on bad engine handling, to complaining pax at badly set cabin temperatures, can cause most systems go havoc - especially since everyone seems to enjoy *watching* lots of ai-planes rather than flying themselves :). Evaluate the need for these carefully. Although this can be pretty impressive from a coding point of view, *most* people couldn't care less - they just want to fly the damn thing :) Whenever I build/modify a panel for personal use, I make several options available on the gauges and can use whatever I like depending on the realism I want to fly under; gauges could be something like:radar_altimeter_simpleradar_altimeter_full (with bank support)altimeter_simplealtimeter_coded (interacts with xpndr and atc on failure)navradio_simplenavradio_full (in case I want realistic reception)asi_simple and vsi_simpleasi_simple and vsi_custom (realistic alternate static failure)With these options available on "delivery" I can choose what kind of setup to use for a particular flight. However, nobody does this, so I make my own gauges and put them in instead.Whenever I download a new aircraft (I still prefer modified default ones though), I put my own (or modified ones) gauges into this aircraft, create the needed modifications to the .air-file and aircraft.cfg and _then_ (and only then) I have an aircraft that I'm happy with. Aircraft that doesn't have an "open" .air-file, doesn't even get installed on my system. Heh, I'm a tweaker, I'm *never* happy with downloaded aircraft without doing my own alterations to it. :D A matter of principle I guess :)As an example, the payware Cessna310 doesn't even *try* to simulate the rather complex fuelsystem. A system I know to be partly possible to simulate with xml only, and I'm pretty sure could be fully (or at least mostly) simulated via C code.Hehe, I did a check on number of bitmaps in my gauges for the C421B. A whopping 675 gauge bitmaps (quite a few sizeduplicates though). And this is a "small" GA plane :( I don't think the number of bitmaps cause a big performance hit, only how often they need to be updated, and the complexity of the code that causes them to update.Although it can be a very daunting task, put as much as possible of the code into the actual clickcode. An example of this. Say you have a timer that starts once power is applied. Instead of having a continous running code (within an element, select, value tagset) which is the really simple way to do it, consider to code the much more complex functions directly into the clickspots for those things driving the power. Sure, it wouldn't work properly in the event of an electrical simulated failure, but the code would only be run when one of the clickspots is actually clicked on. This saves a LOT of time.I've attached some files for reference:The first one is as described above; three electrical switches whose clickspots does a heck of a lot more than simple toggle the builtin functions. The second one is one attempt on several heat distribution switches where all code (diff equations?) where done on the actual clickspots instead of at runtime. These click codes are pretty nasty though. Having them run at real time would have saved a lot of coding time, but cost a lot of frames. It worked exactly as I had planned, but I abandoned it since I couldn't keep track on what actually went on :( Bughunting was a mess though.The third one is the kind of system I use for aircraft initiating. I found however that there is a limit to how much you are allowed to do in one go. These files are FS2002, not sure if all is relevant for FS9.Whups, not allowed to upload more... dinner is finished also, so see ya :) hope this wasn't too waste of space.

Share this post


Link to post
Share on other sites

""But I should be too worried if I were you ""Oops.....Reading it again, I obviously was trying to say:"But I should NOT be too worried if I were you" :-)Cheers, Rob

Share this post


Link to post
Share on other sites

is it normal for xml gauges to take a long time to load.I have noticed that the dc-9 by flight one loads very quickly whereas my panel loads very slowly. Once it does load I can open and close sub-panels fairly quickly.Why does this happen? Is XML more of a hog on system resources that "C"?Thanks,John

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