Thank you so much for your very useful feedback and for clearing up the main issues in this thread. We really appreciate what you and the LM staff are doing for us all.

Kindest regards

Peter

OK. Enough already. This thread is now going nowhere and I have made all the points that I wanted to share with the members. In summary then, the following: The panel gauge update rate appears to be capped at 18hz and that is too slow and needs to be at least 25hz or better. It appears therefore tha...

Your first reference is to bitmap based gauges. It is not a reference to all gauge rendering. In fact, that statement is used to discuss exactly one item. The definition of a needle utilizing a bitmap. It is not the ONLY way to create a needle or a gauge. It's just an easy method. For a gauge defin...

I intend nothing personal in any of my posts including this one. If you can confirm that you do have the knowledge to sort this problem out, then I would respectfully ask that you share this knowledge with LM in order to help all of us solve the problem. In the meantime, I have done some more resear...

The data update rate is at a minimum of 55ms WarpD, may I also point out that it appears that you too have made a typing error in that the maximum update rate of gauges is about 55ms (18Hz) and not the minimum as per your post. On my system I see a draw rate of 30fps... screamingly rock solid. No j...

55ms ( or thereabout) refers

Thanks Ed for pointing out my very obvious typing error. I meant 150ms as stated in my previous post.

55ms ( or thereabout) refers primarily to the maximum allowable hardware interface delay in the process step from switch in my example through the interface to the software and back to the image generator to draw the change of state and that reaction time (transport delay) has absolutely nothing to ...

I believe the 18 times per second issue only affects the redraw of some of the instrument pointers in the cockpit - it's not just the graphics but also any code that was involved in calculating that instrument's display values (scaling,etc.) Dave raises another interesting point here regarding scal...

Correction to typo in previous post

This is in NO way a critisism

The 24(25) flicker rate concept only applies to a dark room (theater) with a single source of bright illumination (the projector) and the persistence of the eye (50 to 100 milliseconds) in that situation - it doesn't apply to monitors. The human eye with monitors can detect stutter/jumps/improper r...

As I eluded to previously, frame rate is essentially only a measure of hardware performance and its ability to render a given scene as fast as possible. The more content it has to render, the slower the frame rate. This however has nothing to do with what I am talking about when I refer to draw rate...

The bottom line is that the current simulation scene update rate of 18 per second is simply too slow. We need at least 25 per second (or better) to get past the flicker threshold of what the human eye can detect (25Hz) I certainly hope that LM can fix this problem and make stutters a thing of the pa...

I write the fuel tank selection directly to the offset via FSUIPC and it works perfectly. If you like, I will look up the offset value in my software and send it to you later. BTW - You can also write the fuel tank value directly to the offset via LUA script linked to an L:Var in an XML gauge. Regar...

I have done some more tests and can confirm that the maximum update rate is 18 per second and it appears that this applies to the entire scene, that is, the gauges and the scenery. That means that if your simulation software is updating the scene at 18Hz and your frame rate is lets say 36Fps then yo...

Thanks Kosta. Generally, the human eye can only detect flicker below 25FPS which is why the old movies were mostly filmed at that rate. So setting a value below that will usually always result in the user being able to detect some flicker (stuttering as I call it) Conversely, anything above that is ...