Breaking 1-degree precision limitations

[greaneyr]

Hi all.

I'm somewhat new to gauge design but not that new to programming. I've been looking at the animated screenshots of the Reality XP gauges (http://www.reality-xp.com/products/FLT/index.htm) and wondering how much work would be involved in creating such gauges. Obviously it's a lot, by way of the fact that their products are payware. I notice aircraft like the Flight1 ATR also use .gau files and in the control program you are able to adjust the refresh rates of gauges so presumably they also use the same technology.

Is there any material on the web which might help with this idea? Or are there other ways of using XML gauges and making them appear smoother?

I've hade a fairly decent look but haven't dug up much as yet.

Hoping someone here can help

Regards
Richard

[n4gix]

XML based gauges suffer from two limitations:

1) they are bitmap based, which is inherently limited in resolution

2) they use 'interpreted scripting' instead of real code

They will never achieve the level of sophistication and smooth performance of vector drawn gauges.

The most common methods used by most are C++ gauges, and utilize GDI and/or GDI+ for their drawing routines. GDI is 'feature poor,' and inadequate for creating high quality work.

GDI+ is more robust, but can be turtle slow if not coded carefully and efficiently.

State of the art may be achived by using the same vector drawing routines that will be used in FSX from Anti-Grain Geometry: http://www.antigrain.com/

Use of these routines assumes a very high level of C++ knowledge and competence.

[darrenecm]

I see the Antigrain technology is mentioned in the various FSX technology papers that have been posted. After looking through the Antigrain documentation you have to marvel at the technique and its algorithms. A job well done indeed.

However from what I can see the techniques are all implemented in standard C++ and C runtime functions, which is great for portability and is absolutely the right choice on the part of the author.

The question is how will this technology integrate itself into FSX? As it is I see no way that Antigrain can be used as it stands without relying on CPU power to do all the drawing. Guage drawing needs to be integrated into the hardware-acclerated realm of DirectX, or OpenGL if you're a DirectX hater :)

I hope we won't see FSX adopting a similarly poor rendering implementation seen in FS2004 where the 3D world visuals are rendered in hardware accelerated DirectX and gauge drawing relegated to a seperate and slower CPU-hogging software renderer (namely GDI/GDI+). This is why the gauge drawing update speeds are limited to the 18 ticks per second limitation.

"Fast enough" you may think but when you move from the 2D panel view into the more popular 3D virtual panel views, each addition of a 3D gauge takes a bite out of that measley 18 ticks per second.

If gauge drawing was part and parcel of a hardware accelerated rendering engine, things would be much more flexible and smoother.