X11GC++, the C++ version of X11GC (New: Dec 23 2003)

• New features compared to the C version of X11GC
  • built-in scripting language based on Lua. This allows simulating things that are \ not provided by flightgear (or another simulator hooked up to X11GC)
  • shares code with the host side program of my PIC HomeCockpit \ Controller (PHCC). Actually, they are both built from the same source tree and can be compiled into one application.
• moving/switching around of displays is now fully implemented and works, even across different computers.
  • this feature allows you to eg. fail the PFD (physical screen) and then tranfer your PFD (screen content) to the \ ND (physical screen).
  • This nice feature is relatively easy to implement due to the network nature of X Window System (aka X11). \ Imagine implementing something like this on eg. native Windows. Must be a nightmare!
• made some small improvements of the EICAS font. That font is based on LetterGothic12PitchBT-Roman \ and LetterGothic12PitchBT-Bold by Bitstream. If you have that font and would like to have my modified version, I can send you a "patch" with the changes. I don't think I can redistribute the whole font. I'd probably have to ask Bitstream \ for permission.

First public screenshots of the C++ version

Note that the grey boxes at the top are not part of X11GC, they are part of the windowmanager I use: ion.

click on thumbnail to view full picture

	PFD, with the start of the speed tape and a nearly 100% functional attitude indicator (the slip part of the "sailboat" doesnt work yet). And of course it needs rounded edges.
	I wanted to make of of the two-engine-Boeing engine gauges... as seen here in this 737/777 kind EICAS. Note the EICAS font. It closely resembles the real EICAS font.
	Same EICAS, simulating an engine spoolup. The spoolup simulation is a 20 liner in Lua, the scripting language built into X11GC.
	My "test" screen, with bits and pieces, including a start of the B744 standby airspeed indictor.
New: Jan 3 2004
	Panel Test. With two Korry Switches and two knobs (and the stdby IAS gauge from prev pic).

The Korry-style knobs, like all other gauges and widgets, are NOT bitmaps, they are drawn using geometric primitives: lines, arcs, ...
This way, they will scale to any size, can be rotated to any angle, without loss of quality. That helps tremendously because the \ user can change the sizes of each window on the fly while the contents (ie. gauges) inside that window will scale along with \ the window size. Additionally, you can place/scale the individual components of each window seperately (inside the program code \ in C++) as seen with the two knobs in the last picture above.

This is an excerpt of the code to produce the knob (in this example, the HYD SYS #4 on the B744 overhead) with legend:

   std::vector<std::string> pnltxt2;
   pnltxt2.push_back("AUX");
   pnltxt2.push_back("");
   pnltxt2.push_back("OFF");
   pnltxt2.push_back("AUTO");
   pnltxt2.push_back("ON");
   panelstack->push(new PanelLetteringRotary(WPos(0.6, 0.4), 0.1, -135.0, 45.0, pnltxt2));
   panelstack->push(new KorryKnob1(WPos(0.6, 0.4), 0.1, -135.0));

X11GC uses a virtual coordinate system that spans from 0.0/0.0 (upper left hand corner) to 1.0/1.0 (lower right hand corner). This coordinate system is independent of the actual screen and window size.

The following are the class declarations for PanelLetteringRotary and KorryKnob1 that were used in above excerpt:

class PanelLetteringRotary : public SimpleWidget
{
  public:
        PanelLetteringRotary(WPos _pos, COORD_TYPE _size, double _startangle, double _angleincrement,
                             std::vector<std::string> _legends, bool _active=true,
                             std::string _onchangeactiveprop="", std::string _onchangeprop="")
            : SimpleWidget(_pos, WSize(_size, _size), _active, _onchangeactiveprop, _onchangeprop),
              startangle(_startangle), angleincrement(_angleincrement), legends(_legends) {}
...

class KorryKnob1 : public SimpleWidget
{
  public:
        KorryKnob1(WPos _pos, COORD_TYPE _size, double _switchangle, bool _active=true,
                   std::string _onchangeactiveprop="", std::string _onchangeprop="")
            : SimpleWidget(_pos, WSize(_size, _size), _active, _onchangeactiveprop, _onchangeprop),
              switchangle(_switchangle) {}
...

Both classes are descendants from a base class "SimpleWidget" which does most of the common work. All you have to do for classes derived from SimpleWidget is to implement the "void Paint()" method which gets called when a redraw is necessary, eg. resizing a window, redirecting screens, when another window or application overlaps, or when an internal variable/property gets changed for which the Widget is registered to receive updates.

---

screenshots from the old C based version of X11GC (see below for larger versions)

X11GC Overview

• our Glass Cockpit Software Suite is specifically designed NOT to require or use OpenGL, thereby
  • it can run on lowly Pentium I < 200MHz class machines
  • maybe even 486...
  • initially in C, now redesigned and re-written in C++
  • just one binary executable running all the displays
  • based on X11
    • uses only bare X11 calls
  • uses Postscript Type1 fonts via t1lib
    • fonts might not be free/GPL ... this has yet to be determined
  • distributed architecture:
    • one Machine runs the actual program (this is the X-Client) this wouldn't even need a screen connected to it :)
      • but that machine should be a little stronger
    • this X-Client connects to one or more X-Servers to show the displays (PFD,ND,EICAS,CDU) on one or more screens
    • of course, the X-Client and the X-Server can run on the same machine as usually seen on most home linux installations
    • since each display (PFD,ND,EICAS,CDU) can connect to a different X-Server, any of the following combinations are possible:
      • two or more on a screen
      • one or more on each screen on a multiheaded system(ie. multiple graphics cards, or Dual/Quad/whatever Head VGA cards)
      • each on a different machine/screen
      • and more ...
  • all thats needed on a remote X-Server is the Operating System and of course the X-Server.
    • this might open the possibility for a minimal boot floppy based X11 system, or
    • a stripped down version of Knoppix, a bootable, fully CD-hosted Linux System
  • the architecture of X11GC allows you to simulate failures of cockpit displays.
    • you can reroute every "application" (eg. PFD/ND/EICAS/CDU) to any hardware CRT/LCD screen
  • X11GC doesn't have to be installed on every computer running X11GC displays, just install the binary on one machine (the X-Client)
• feasibility of running under windows
  • there are a couple of commerical (ie. payware) X-Servers for windows available,
  • but since XFree86 has been fully ported to windows, this would probably be a good choice if you MUST run windows
    • available here: XFree86 for Windows Windows port
    • mixing windows/linux/... is also possible
• very similar to flightgear, we will use a property manager to manage the internal state of the displays/simulation
  • a property tree is similar to a filesystem, where the branches correspond to directories, and leaves to files
  • leaves store a value and its type
  • several interfaces to the property tree are planned:
    • using telnet to connect to the property manager allows one to navigate the tree like a filesystem (flightgear has that)
    • XML interface (sad but true, we'll jump on the XML bandwagon :-)
      • in cooperation with Dirk Anderseck, this might open up a way of interfacing the displays to the popular FSBus cockpit hardware interface
    • serial interface for our own hardware, possibly USB in the future (when Microchip comes out with the flash-based line of USB capable PIC microcontrollers)
    • possibly a python module for scripting
  • a change of a leaf's value can trigger certain actions, eg:
    • a change of the N1 value of an engine will change the pitch of the engine sound
    • turning the range knob on the Captains EFIS panel will change the corresponding entry in the property tree via the serial interface, whereupon the Captains ND gets notified to display the new range setting.

Screenshots of the older C based version of X11GC

click on thumbnail to view full picture

	the Primary Display as it is right now. One thing that I realized looking at pictures over at airliners.net was that the compass card shows a 60 degree arc, however the real angle of the visible part of the compass card circle seems to be about 90 degrees (ie. the numbers and tickmarks are stretched by 1/3rd) Even Project Magenta apparently got that wrong :)
	This is the Primary Display in offline mode.
	The Primary EICAS... note that the numbers are just arbitrary... they are actually generated with a joystick for testing. You can see the flaps are in transit... to 10, shown in magenta.

Fonts

• I found a Type1 font that looked very similar to what the real Boeing EICAS/PFD/ND screen fonts looks like
  • I changed some characters (with this program: pfaedit) to better macht the real thing. Looks good now :-)
  • see below for some screenshots of the fonttable
  • however I don't think I can redistribute the modified font. Maybe I'll email the font vendor and ask if they'd consider GPL'ing them :-)
  • the "real thing" uses a monospaced font, whereas the font used on the old screenshots above is a proportional font. The font in the screenshots below is actually a monospaced font :)

Screenshots of the modified font

They still need some work. Esp. the "I" of the Regular version. So do the '6' and '9'. The 6 is not just a rotated 9.

Regular

Bold