Sign in to follow this  
Guest Charlie November

VC gauge refresh rate

Recommended Posts

Is it possible to edit the refresh rate of the gauges in the Virtual Cockpit. The refresh rate in the default aircraft is ok, but in some addons it is just unacceptable and makes it impossible to fly the aircraft precicely. The gauges just acctualize once a second or so, but for the VSI and attitude i think it requires minimum 10 times a second.I already tweaked my system to have a constant FPS of 17 and the sim runs fine but the gauges dontDoes this happen on every system ill be grateful for every tip

Share this post


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

To bump up this old topic I found, has there been any fresh thought about this subject? The very same thing annoys me a lot with most, if not all addons, be payware or freeware.I can understand why the gauge performance is bad if the overall performance of the computer is bad, but if I have a solid 20-25 fps in the cockpit, why is it not possible to refresh the gauges at a similar rate? An internal FS restriction?Just wondering..-kyle

Share this post


Link to post
Share on other sites

As far as I'm aware, the only command in XML that deals with "gauge refresh" actually slows down the refresh rate, which - on the face of it - seems rather silly and pointless! :(

Share this post


Link to post
Share on other sites

Bill, Are you referring to the UpdateRate statement in XML ??If so:see this post:http://forums.avsim.net/dcboard.php?az=sho...id=17969&page=3One reason why slowing down XML gauges could be usefull...But for the original question: I don't think it's XML gauges only that have this effect (although they might if a low UpdateRate is used).A lot of .gau gauges show this "stuttering" effect as well.While exactly the same gauge works OK in the 2D cockpit, when shown in the VC, the gauge is very jumpy (i.e low refresh rate).In fact, in that situation ALL the gauges in that VC panel are slow and sluggish as far as I can remember. SO I don't think it's the gauges themselves, but the definition of the VC panel.Only question remains: WHY :-) ???Rob

Share this post


Link to post
Share on other sites

The "why" is a confluence of several, separate factors, none of which will have too much effect by themselves, but the cumulative effects are sometimes horrid.First, let's set aside for the moment the processor, bus speed, HD speed, etc. and assume that we're using a upper-mid to upper end system, and that framerates are fairly constant ~16 at a minimum.The biggest "hog" on resources will be the size and quantity of the '$panel.bmp' files. Using the absolute fewest possible, while still keeping the maximum resolution possible is the ideal. I'm astonished that some folks have chosen to have a separate '$dummy.bmp' for each gauge (that's one extreme), and others have opted to use only one for the entire VC...I've remapped the entire TB20GT and reduced the number of gauge maps from FIVE to only TWO, 1024x1024 maps, and managed to actually increase the gauge resolution in the process. At the time I made the re-map of the VC, I was still using 100% XML gauges. That single step of consolidating multiple gauge polys onto a single 1024 square .bmp increased the VC refresh rate by a very noticable amount. At a guess, based on my comparisons of a before and after test, the delta is around 25% at least.The second reason for slow refresh rates are the individual gauge elements themselves, irrespective of whether the gauge is XML or C coded. Using 8-bit texture elements where possible makes a HUGE difference in the final gauge size, and hence the degree to which a particular gauge bogs down the system.The third reason is the programming technique used. Sloppy code in either XML or C will cause a general slowdown, as the processor digests and processes the information. Repeated calculations of the same variables is not only wasteful, but redundant. Do the math once and store the result to a custom, shared variable. I know in these days of fast processors and megabytes of memory, there is a tendency to emulate the software giants with their bloated, sloppy programming, but we (that is, gauge designers) need to recall the techniques of decades ago and write tight, optimized code. With C gauges, do as much of the 'math' as possible during the panel load, so it won't have to be done later.A fourth reason is the nature of XML itself. Since XML is not a "programming language," but rather a "recipie of instructions," the run-time interpreter has to continuously re-parse the same instructions, pass them to the processor as machine language code, and the sim then executes them, ad infinitum.These are four of the reasons that I've found to be the largest contributors to the VC refresh problem, but I'm sure to think of more as time goes on. :)Oh yes, that TB20GT I spoke of earlier? I've since recoded the entire panel in C, and have another ~25% improvement in VC refresh speed... :-ukliam

Share this post


Link to post
Share on other sites

Thanks for this insight Fr.Bill. Have to admit the Socata is one of those planes in which the problem does not jump in yr face like it does in several high-quality planes. So you've done good work.Will have to look into it more..

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