Questions Around Gauge And Dll Programming

[WarpD 824]

That's not a very valid test. Try the same with non-GDI+ gauges rendering the same amount of information (graphics wise). Not eliminate the panel entirely. That only tells you how much faster the sim runs without ANY gauges.As I stated... the Cit X v2 has a great deal of GDI+ rendered gauges in the VC... pretty much all the gaugework except for the standby instruments.A typical rendering time for it's PFD is ~3ms.When discussing 'hardware acceleration'... keep in mind... the graphics card has zero access to flight sim variables and thus wouldn't have a clue regarding object rotation/translation in coordinating with FS. It isn't going to actually do one bit of the rendering for you. Zip, zilch, nada.The only advantage you could gain with using video memory is a reduced 'swap time' to bring your render to the screen. And if that's your bottleneck, you're doing it wrong from the get-go.

[WarpD 824]

Here's an image of our 2D panel. Note the frame rates. Every gauge on the panel is a GDI+ gauge except the analog (standby) instruments.http://i107.photobucket.com/albums/m316/wa...framerate2d.jpgMy system is a P4 3.4ghz... so it's not a current system by any stretch of the imagination. :(

[Guest darrenecm]

That's not a very valid test. Try the same with non-GDI+ gauges rendering the same amount of information (graphics wise). Not eliminate the panel entirely. That only tells you how much faster the sim runs without ANY gauges.As I stated... the Cit X v2 has a great deal of GDI+ rendered gauges in the VC... pretty much all the gaugework except for the standby instruments.A typical rendering time for it's PFD is ~3ms.When discussing 'hardware acceleration'... keep in mind... the graphics card has zero access to flight sim variables and thus wouldn't have a clue regarding object rotation/translation in coordinating with FS. It isn't going to actually do one bit of the rendering for you. Zip, zilch, nada.The only advantage you could gain with using video memory is a reduced 'swap time' to bring your render to the screen. And if that's your bottleneck, you're doing it wrong from the get-go.

Not sure what you mean there Ed. I'm likely misunderstanding you but are you assuming flight simulation variables are to be stored in video card memory? If so that's not the case. That would also imply gauge logic code would be stored in video memory. Only the drawing surface, any bitmap sprites for common avioncs graphics (including font and image bitmaps), vertex lists representing common vector shapes (including any vector fonts or stroke-based fonts) for avionics graphics etc would be stored in video card memory. And as for the 'swap time' you mention, there would be hugely reduced need for image data to be swapped from system to video memory because you would be rendering to a surface directly in video memory (or more likely a backbuffer that is blit-copied within very fast video memory to a primary buffer. GPU (Graphics Processing Unit) blits leave CPU blits coughing in the wake of their dust).All your gauge simulation variables would still reside in system memory. You would then make your draw calls sending updated rotation, position, colour changes, fill gradient information as numeric paramaters to these draw calls. Once the draw calls send this small amount of updated information, the CPU then moves on to other things and lets the GPU handle clearing the surface, then processing the rasterisation of all imagery based on rotation, translation and scaling (based on new numeric values sent in draw calls). The GPU would also handle solid fills, gradient fills, pattern fills, copying bitmaps, scrolling bitmaps, scaling bitmaps, applying overlay effects to bitmaps (transparency, tinting etc), clipping, changing brush colors and many other things.There's a whole lot of CPU horsepower going on in a single GDI+ draw call and a lot of it is in rasterisation - which is basically lots and lots of memory manipulation as many bits are shuffled around to create bitmap imagery, lines and arcs etc in memory. All this would be handled by the GPU in a hardware accelerated world while the CPU gets on with other things such as further gauge logic processing and servicing the needs of other FSX system calls. Also, the more gauges you have in a cockpit, the greater the savings in rendering time as the sum of all the time spent rendering in a software-based rendering world is handled concurrently by the GPU.It's probably difficult to envision a CPU / GPU rendering pipeline from a software-based renderer perspective because of the concurrent nature of the processing between the CPU and GPU. In a software-based renderer, the CPU is processing the gauge logic and the rendering code in a linear fashion. Also, in a real-time graphics processing world involving CPU / GPU rendering pipeline you need to adjust your thinking into 'batching' your draw calls. This was a bit of an eye-opener for me when first encountering real-time hardware acclerated graphics, requiring quite a rethink in how often I called and where I had all my draw calls.This very aspect of draw calls and 'batching' is what the cool FSX service packs addressed and why applying the service packs drastically improves FSX framerates. I assume the dev team had discreet draw calls all over the place and have since made heavy use of batch rendering in the SP1 and 2 updates.After dipping into DirectX, getting a serious headache and then discovering the much easier to understand world of OpenGL, you soon realise the benefits of all this concurrent processing that hardware acceleration (which is bsaically offloading processing to the dedicated GPU) brings :)Ultimately we might be able to look forward to a much cleaner gauges.h file and better interaction between gauge code and the FSX engine that would allow easy seperation of suitable gauge logic into it's own thread, allowing it to be processed on seperate cores on multi-core CPUs. This would further spread the CPU load and in association with the GPU concurrently handling rendering loads, greater performance would be achieved for other FSX goodies such as higher levels of autogen, smoother terrain streaming, more complex weather, traffic and 'living world' processing etc.Things actually look quite good for a world of programming languages that provide mechanisms for programmers to easily utilise concurrency in this burgeoning world of multi-core processors. Implementing multiple threading and multi-core processing in your code today is frought with all manner of problems and synchronisation headaches, but Microsoft's next generation of updates for Visual Studio languages seem set to include powerful APIs that make all this multi-core programming really easy. Wether or not this will allow you gauge gurus to work this magic in the current confines of the FSX and gauge code system of interaction is another matter though, which is why I hope we will see efforts made to move away from the current manner in which the Flight Simulator SDK allows us to draw gauges in the next Flight Simulator iteration, and hardware accelerated gauge drawing needs to be a part of it :)

That's not a very valid test. Try the same with non-GDI+ gauges rendering the same amount of information (graphics wise). Not eliminate the panel entirely. That only tells you how much faster the sim runs without ANY gauges.

Ed's right, that's not a fair test. Again I wish I really knew enough about GDI+ to do some useful comparisons with other APIs like OpenGL, AGG etc :)

[Guest darrenecm]

Anyone interested in my reference to concurrent programming becoming much easier in the future thanks to efforts from Microsoft should point your browsers to the link below:http://msdn.microsoft.com/en-us/magazine/cc817396.aspx

[WarpD 824]

'Concurrent programming'... um... it's called threading. Has been around for ages. Yeah, I know... there's a physical hardware difference... but on the software side... there really isn't.

[Guest darrenecm]

Here's an image of our 2D panel. Note the frame rates. Every gauge on the panel is a GDI+ gauge except the analog (standby) instruments.http://i107.photobucket.com/albums/m316/wa...framerate2d.jpgMy system is a P4 3.4ghz... so it's not a current system by any stretch of the imagination. :(

There's another side to the equation to keep in mind when we are talking about overall framerates, and that is the current level of detail of the FSX simulation settings you are happy with.It all depends on the importance each FSX simmer places on the balance between how things look, the quality of immersion of the simulated world and the responsiveness provided by the average framerate. I for one like detailed weather with volumetric clouds and decent levels of commercial and GA traffic, plus road traffic. I much prefer IFR style flying in 'tricky' weather. There's nothing like flying on instruments in the soup, flying an approach to minimums and breaking out of the clouds to find the runway all lined up nice in your GA aircraft - none of this automagic, button-pushing, dial-twisting jet business for me, no sir :)I'd love to get into more VFR flying but the processing costs of autogen or VFR-city style add-ons and real-world textures (preferably with night-textures support) and all at reasonable levels of detail to navigate accurately by, while maintaining my personal minimum of 30 fps do not seem doable at this time. At least not on my Athlon 64 FX-57, 4GB Ram, 2 x 400Gb SATA HDDs and GeForce 9800 GX2 system.Highly detailed add-on texture packs based on real-world aerial mapping imagery are not good enough for me, I also want to see sufficient details in the terrain height and other 3D object references like cities, towns and other landmarks.I'm probably severely CPU-bound with my single-core system, but I'm not sure whether even a 4-core processor would make accurate and realistic VFR in FSX at a steady 30 fps enjoyable for me. Probably time to upgrade and find out I guess :)Therefore the ability for gauge and aicraft add-ons to take as little a slice out of my base framerate, allowing enough CPU time for FSX to present a world detail that is acceptable to your own personal tastes is important.

[WarpD 824]

That image was in FS9 with all detail sliders to the right. All of them.There isn't a CPU setup today that likes FSX with all detail sliders to the right.

[Guest darrenecm]

'Concurrent programming'... um... it's called threading. Has been around for ages. Yeah, I know... there's a physical hardware difference... but on the software side... there really isn't.

Just because you slap something in a seperate thread does not mean it automatically runs on another core, thereby spreading the load intelligently. I'm highlighting the nature of concurrency, or to paraphrase you "um...threading" in the context of the growing surge of multiple cores appearing and achieving 'true' parrallel programming. I'm also pointing out how tricky it is for programmers to make full use of threading when you have shared data thrown into the mix. Which is why Microsoft's latest additions to the Visual Studio languages are exciting to me because they will make synhronisation headaches less painful.Threading may well have been around for ages but things really happening at the same time in different threads has been pure illusion until recently. Threading on a CPU in the past was not parallel, your code was being time-spliced with existing running code but ultimately all running one after the other. The CPU was simply running fast enough for it to appear concurrent. Things are changing now thanks to GPU's and multi-core CPUs

[Guest darrenecm]

That image was in FS9 with all detail sliders to the right. All of them.There isn't a CPU setup today that likes FSX with all detail sliders to the right.

Firstly those two paragraphs appear mutually exclusive to me given the fact that the 38 fps shown is a very acceptable figure to me. If you have all detail sliders to the right then how does that tally with the statement in your second paragraph?There's also the issue of just where you are in the world. Your screenshot is at night and you are on a runway so there's no indication of surrounding terrain complexity, texture quality, traffic levels, actual clouds being rendered as opposed to it just being a clear night etc. It all depends on what the simulator is currently handling at your given location and what is actually in view out of the cockpit. I too can have all sliders maxed if I'm flying in a very sparsley populated part of the UK, with clear weather, at a small default airport.What I look for is a performance from an add-on that will not send me dipping below my personal 30 fps minimum as soon as a reasonably detailed airport comes into view with AI planes and ground vehicles in view because it's taking a non-trivial slice from what I normally get.As I said, each of us has different levelks of acceptable simulation rates when in even the most detailed of surroundings but it's difficult to gauge the importance of that decent FPS figure in the screenshot when there appears to be very little going on in the view shown out the cockpit :)

[WarpD 824]

And yet... the requirements for safe threading are the same for safe multi-core.To implement a multi-core application... one takes advantage of using multiple threads. Microsoft may have changed their name... but the sheer nature of the beast is actually one and the same.I've been doing threading for years and years... so multi-core is no different to me. Thread-safe is core-safe.

[WarpD 824]

Firstly those two paragraphs appear mutually exclusive to me given the fact that the 38 fps shown is a very acceptable figure to me. If you have all detail sliders to the right then how does that tally with the statement in your second paragraph?There's also the issue of just where you are in the world. Your screenshot is at night and you are on a runway so there's no indication of surrounding terrain complexity, texture quality, traffic levels, actual clouds being rendered as opposed to it just being a clear night etc. It all depends on what the simulator is currently handling at your given location and what is actually in view out of the cockpit. I too can have all sliders maxed if I'm flying in a very sparsley populated part of the UK, with clear weather, at a small default airport.What I look for is a performance from an add-on that will not send me dipping below my personal 30 fps minimum as soon as a reasonably detailed airport comes into view with AI planes and ground vehicles in view because it's taking a non-trivial slice from what I normally get.As I said, each of us has different levelks of acceptable simulation rates when in even the most detailed of surroundings but it's difficult to gauge the importance of that decent FPS figure in the screenshot when there appears to be very little going on in the view shown out the cockpit :)

The two paragraphs are about two separate versions of the sim.You, like so many others translates the gauge performance as being the 'impact'. Because of the brute-force design of the underlying FS architecture... that's an honestly incorrect conclusion. If your panel requires 2ms to render the entire panel, all gauges... that falls well within the simplistic requirements of the FS process loop. However, there is nothing to prevent other aspects of FS from starving your gauge process to the point you still get stutters... frozen gauges... etc. The only time your gauges are the impact is when you can not process your panel within a reasonable amount of time. The definition of 'reasonable amount of time'... is unfortunately a sliding scale in FS. It's a sliding scale you have no control over.... and you probably never will.I've gone through this, code-wise, in an extremely extensive process... and found that the #1 bottleneck for FS isn't the gauges... it's the 3D terrain and drive access more than absolutely anything else. The more data required from the hard drive... the more time sliced out of the FS process loop. The more 3D terrain processing (finer resolution mesh)... the more time sliced out of the FS process loop.I actually set up a panel that rendered in 0.05ms (yes, that's right)... yet could still get stutters, slow terrain loads... jerking gauges. Because it's all about the FS process loop... of which you have zero control or influence of.An extremly well performing gauge can look like total crap if you utilize it around a 3D object (airport bldg) that's drawn in less than optimal conditions. Eaglesoft's Twin Commanche is an aircraft that has absolutely amazing rendering performance... because the 3D model was optimized to produce minimum impact to the rendering cycle. Most airport addons do not fall into that category... yet it's the aircraft/gauge(s) that take the blame.

[Guest darrenecm]

And yet... the requirements for safe threading are the same for safe multi-core.To implement a multi-core application... one takes advantage of using multiple threads. Microsoft may have changed their name... but the sheer nature of the beast is actually one and the same.I've been doing threading for years and years... so multi-core is no different to me. Thread-safe is core-safe.

I bow to your experience here but one of the points I was hoping to get across is how difficult it is to have true concurrent processing in games thanks to seperate processors, not just the time-spliced illusions we've had untiol recently on single-core processors. It requires a lot of effort to make something thread safe and free from multiple threading bugs. Just as much effort as coming up with your own 2D vector software rendering engine to imrpove upon GDI+. Do you use multi-threading to imrpove performance in your gauges Ed? If not why not? I suspect it's because it's notoriously difficult to write thread-safe code, as well as debug it.The point is that Microsoft is introducing APIs that make parallel threading even easier in youir chosen languages, which means we should start seeing major improvements in all levels of consumer software because much of the hard work of implementing parallel processing has been written for you. Much like the reason why many of you are using GDI+ instead of plain vanilla GDI.

[WarpD 824]

I won't discuss what I do behind the scenes in my commercial gauges. :( I'm all for discussing possibilities... but I won't give away what one might call trade secrets. :(

[n4gix 4,947]

Firstly those two paragraphs appear mutually exclusive to me given the fact that the 38 fps shown is a very acceptable figure to me. If you have all detail sliders to the right then how does that tally with the statement in your second paragraph?

Darren, Ed's first statement references FS9.Ed's second statement references FSX.Ergo, there is no contradiction... :(

[Guest darrenecm]

I won't discuss what I do behind the scenes in my commercial gauges. :( I'm all for discussing possibilities... but I won't give away what one might call trade secrets. :(

Bah...foiled again.

You, like so many others translates the gauge performance as being the 'impact'. Because of the brute-force design of the underlying FS architecture... that's an honestly incorrect conclusion. If your panel requires 2ms to render the entire panel, all gauges... that falls well within the simplistic requirements of the FS process loop. However, there is nothing to prevent other aspects of FS from starving your gauge process to the point you still get stutters... frozen gauges... etc. The only time your gauges are the impact is when you can not process your panel within a reasonable amount of time. The definition of 'reasonable amount of time'... is unfortunately a sliding scale in FS. It's a sliding scale you have no control over.... and you probably never will.

I may be judging things from a point of misunderstanding regarding my less than stellar view of GDI+ gauges and my original comments about alternative rendering methods that might utilise hardware acceleration for improving things. To be up front about it all I am basing my viewpoints from the following position. If I'm missing something and completely wrong about the following observations about gauge impact, please let me know.I've got FSX Gold Edition installed on Vista 32-bit. I bought the Eaglesoft SR22G2/G3 Turbo for FSX add-on. I load FSX and load my saved Free Flight default set up, which is a default FSX Cessna 172 with engines and avionics running, 2D internal cockpit. With this my system shows an unlimited average framerate of between 100 and 110 fps. Without changing any settings I use the Load Aircraft menu to load an SR22G2 and my framerate drops to between 38 and 51 fps on average straight away. I'm quite happy with this Eaglesoft product but I do find that the immediate drop in framerates means I'll need to lower some FSX settings that I already consider at minimum levels in order to claw back some FPS headroom. The depressing thing is that even if I go through all the tabs for details settings and set everything to Minimal, I only achieve an average fps of 61. I'm not sure if I'm being unfair but to me that drop just feels a tad too much.I guess the only true measure of things is to compare it against another product using a similar gauge with similar features, maybe the Flight1 Avidyne Entegra product? But then again there's scant information on what API Flight1's product is using for rendering. For all I know it too uses GDI+. Heck for all I know Eaglesoft may have licenced it's Avidyne gauge tech as a standalone package for Flight1 to distribute - unlikely but possible :)Maybe I'm also tainted by discussions with fellow amateur coders in the past whilst learning to program games. Many used GDI+ initially because it was relatively approachable to newcomers for graphics rendering rather than DirectX. but as some of them gained more experience and eventually moved onto DirectX or OpenGL, they did so after having used GDI+ extensively. I started using OpenGL early because most of my friends already had good experience with it.In talking with these friends they were telling me that it's not just that GDI+ rendering calls are CPU bound, but that the basic GDI+ subsystem tends to take up non-trivial resources and CPU time to manage it's internal data structures and objects such as pen and brush contexts, color structures and other systems.Maybe this is a good time for me to revisit my success at getting OpenGL up and running within a gauge during my time spent dabbling with FS2004 SDK. I was actually having chats with Ron, Bill, Stasi and Tiberiu, whom I imagine you know. I imagine Ron was interested in seeing if using OpenGL, whether hardware accelerated or not, would provide suffucient increase in performance to existing methods at Eaglesoft.Sadly, real life job-hunting issues, plus the fact I was still a C++ noob, was unfamiliar with the FS2004 SDK and didn't know much about GDI+ meant I couldn't spare the time needed to come up with 'proof of concept' samples. Maybe in the New Year I'll be able to find some time.Speaking of which, it's 11:55 here. Time to rush back to my friends down the road and see in the New Year.I hope everyone has a great one.