James Turner schreef: > <snipped> > - My plan would be to build some generic classes which can be extended > or configured to support Boeing or Airbus displays, or other similar > systems (including the G1000). My current perception is that this > would be pretty doable - sizes / colours / iconography / positions of > elements change, but the fundamental concepts are pretty consistent. > Does this seem reasonable? Obviously supporting all the features of > each system is an immense amount of work, but I think getting the > common features up and running is doable in the medium term. > > - Any other feedback? I'm interested in docs on the G1000 and Airbus > displays / FMS in particular, to see how they differ from what i know > about the Boeing ones. I don't know anything about military > equivalents, but maybe they are also similar enough to share a C++ core. > > My initial hack would be to get a NAV display running showing the > current route segments and navaids overlays in a specified radius, > working as a custom panel instrument. That would be enough to get the > FPL/WPT/APT/FIX/NAV/etc buttons in various cockpits working, as well > as the NAV display modes (compass, enroute, approach if I recall > correctly). > > Regards, > James > I've been a lurker on this list for quite a while, and some of the FG development crew know me personally. I would be interested in helping out with this, since I am a sim builder and I think the interface for cockpit displays is probably one of the most important things missing in FG at the current time, in terms of the usability for sim building. After all, the flight dynamics and system logic of FG are far better than its Microsoft cousin.
Remember, in real-world aircraft, cockpit displays are vector devices. In most sim packages, including FG and FS200x, panels are built by stacking bitmaps on top of each other, according to a specific transformation (fx. the attitude indicator consists of a static mask bitmap and an attitude card which is translated and rotated according to the aircraft's pitch/roll). Although this works very well for 'classic' mechanical gauges, it loses its function when simulating glass displays as it primarily compromises the readability of text. (this isn't a huge issue in mechanical gauges, since they have big numbers and mostly static text number plates. Glass decks, on the other hand, have a lot of transformed text) My suggestion would be to look into the option of making a vector framework, which has all the basic widgets for a glass deck implemented in C++ code. I'm guessing it would be somewhat similar to ARINC661, and the actual arrangement of these widgets could be marked up in an XML file. The framework could render to a texture (for display in a 3D virtual cockpit), a memory buffer (for direct blitting onto the screen) or to a separate device context altogether (for an external display). Network support on this would be a really interesting feature -- allowing outboard 'dumb' cockpit displays to be run off a diskless thin client. I have done some preliminary research on this and some bits of code. I currently have a working example of the Primus 1000 avionics set as seen in the Embraer ERJ-145, but it currently only connects to MSFS. Here's a pic: http://www.stoneynet.nl/openrj/openrj_screenshot.png And here's a ZIP containing the binaries, for the people interested in playing with it (Windows only): http://www.stoneynet.nl/openrj/openrj-0.9.7rc1.zip All the individual displays are plug-in files (Windows DLL files), but for the 2.0 version of the framework I'm trying to stick with UNIX support as much as I can. Most of the code inside the plugin file is just plain OpenGL commands and some math, though, and I reckon this could be easily translated into geometry files (XML or binary for embedded purposes), containing only the display engine in code. Making a moving map (NAV) display is pretty easy, BTW. The simplest, but least accurate way of doing it is to use a rectangular mapping -- mapping latitude and longitude to the X and Y axes directly. Remember that 1 minute of lat/longitude corresponds to 1 nautical mile by definition, and calculating distances is a snap (using the Pythagorean theorem). Define the clipping region of the map using glOrtho in nautical miles around the aircraft (the aircraft is positioned at the origin) and scale the coordinates up 60 times to obtain the easiest mapping. A more accurate mapping can be achieved by drawing the map in 3D, this also solves wrap-around problems, but it is (marginally) slower because of the large number of rotations involved. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
