I once in time wrote some C++ (actually Java and ordinary C) and my knowledge aboout the FG system is very basic.
To be honest, in many places in FlightGear's source code, C++ use of more modern/advanced features is still fairly limited.
Much of the source code is pretty much implemented as "C with classes and the STL", this applies in particular to the majority of legacy code.
It is only since pretty recently that the FlightGear source code is being modernized, which is mostly caused by new dependencies like OSG or Boost that make use of more advanced C++ techniques, like for example traits.
And there is also a pretty comprehensive amount of introductory information available on C++ programming here:
http://wiki.flightgear.org/index.php/Pr ... _ResourcesIMHO having 661 specs is a quite central issue in a possible approach. If I remember well, a CD with the last 661 specs is about $500.
I agree, having access to the full ARINC 661 specs would really be required.
But 500 USD for a CD with specs is quite ... hefty. Especially for a single developer without financial backing from a company to work on this.
Even more so in an open source project, where there is simply no funding available for such purposes.
Without access to the ARINC 661 specs, this would be pretty a giant much reverse engineering effort. Which would still be doable, as long as you have access to software for creating valid ARINC 661 XML files (or a huge set of valid files). Just looking at some of the examples (i.e. wikipedia or from the blog you posted), processing the XML should really not be too difficult at all.
Personally, I would also suggest to refrain from trying to support the binary "Definition Files" in the beginning - and instead concentrate on XML only.
This is because it would be much easier to directly work with XML files, without converting them to the binary equivalent "Definition Files".
Given that these binary "Defintion Files" are compiled from XML files, this should not make any real difference at all, but still simplify the development process.
So the costs might be a real hurdle at this point.
One could try to get in touch with
standards@arinc.com and ask them if there are any ways for getting access to important details without having to buy a CD for 500 USD.
But given that ARINC 661 support in FlightGear would enable some companies to save some real bucks, it might also be possible to ask for financial support from such companies or organizations that would benefit from such an enhancement, to help sponsor such an effort.
There is some information on ARINC 661 available here:
http://www.presagis.com/files/section_p ... %20v07.pdfBasically, widgets are based on categories (quoting the PDF file):
- Container: A widget that can contain other widgets to define hierarchical organization or to provide functionality (e.g. MutuallyExclusiveContainer)
- Graphical Representation: A widget that draws graphics (e.g. PushButton)
- Text String: A widget that renders text (e.g. PushButton)
- Interactive: A widget that reacts to interaction from the user (e.g. PushButton)
- Map Management: A widget related to the rendering of a map inside of an ARINC 661 display (e.g. MapHorz)
- Dynamic Motion: A widget that can be repositioned while the display is running (e.g. GpLine)
As we can see from these examples, a widget can belong to more than one category based on its functionality.
The other would finding an opensource 661 server and a "general purpose" client in order to no needing code scratch should made easy to evaluate.
Yes, I absolutely agree that having access to an open source ARINC 661 server would be perfect for this project, but I am simply not aware of any such projects.
If I am not mistaken, the link to the blog you posted is also not specifically about creating just a server component?
But looking at the blog, the author is apparently part of the ARINC 661 committee, so he might be the best person to talk to in order to get access to some more details for implementing ARINC 661. Maybe just an outdated PDF draft that does not cost 500 USD?
After all, one would not necessarily need access to the latest version of the specs (ARINC 661-4), a working draft would be sufficient to have something to start with, for prototyping purposes.
If you are still interested in working on this, I would try to get in touch with him and maybe even point him to this discussion, because he seems clearly to be interested in this sort of work, so getting some more feedback would surely be valuable.
Maybe he is even interested in teaming up with us to create a generic set of ARINC 661 server/client components, which could in turn be used by related projects, such as a module that allows ARINC 661 XML DF to be rendered directly in FlightGear?
We would mainly need an ARINC 661 kernel that can be linked to different rendering backends (OpenGL/OSG in the case of FG), so that the CDS could be visualized in FlightGear.
Even if the blog writer should not be specifically interested in contributing to FlightGear, teaming up with any ARINC 661 related projects would make sense in my opinion.
I mean, one could also develop the ARINC 661 server/client framework separately and then only interface it with FlightGear by using some form of IPC to remotely render graphics in fgfs, provided by another process. That would ensure that there are no project specific dependencies introduced (FlightGear, XUL etc), so that different projects could implement the rendering backend separately.
This has actually been discussed here several times already, and there is apparently some interest to add such a feature to FlightGear, so other standalone programs may work like a "plugin" that remotely renders graphics in FlightGear.
It is currently not yet possible to create dynamic instruments outside the fgfs process space, to have them rendered in FlightGear.
So while there is currently no network capable rendering API in place, it should be possible to provide such a facilty once a real need arises.
Imagine a scenario where you 1) connect to a running fgfs process using a socket, 2) create a remote rendering context and 3) then draw primitives by issuing 2D drawing commands via a network connection. FlightGear would then dynamically draw to texture, according to the commands it receives from the other process.
So such an enhancement would make it possible to render instruments without having to modify/recompile FlightGear, pretty much like a standalone plugin system.
I am myself interested in this sort of thing, and we were actually talking about something very similar like this just a couple of months ago:
viewtopic.php?f=6&t=7383&p=70236It would be possible to extend the idea even further and provide a way to allow external programs to draw to textures using a socket connection.
I don't think this would need to be too complex in the beginning:
It its simplest form, you would just expose a "SetPixel(x,y,color)" routine.
More complex drawing primitives (e.g. lines, rectangles, circles) could be added later on.
These would then be directly mapped to their corresponding ARINC 661 equivalents, like:
So the low level ARINC 661 widgets would need to be mapped to the corresponding OpenGL primitives (GL_POINTS, GL_LINES etc), while the more complex widgets (like e.g. MapHorz), would need to be separately implemented (pretty much like the current Map dialog).
While there are many different ideas now for providing 2D drawing support (XML files, Nasal scripts, SVG support, cairo, network, ARINC 661), the common requirement would really be to first have a 2D drawing API in C++.
If you are still interested in working on this, and once you are able to build FG from source, I can provide additional help and pointers for getting started hacking FlightGear. I could for example send you a patch for a simple generic instrument that can be used for drawing to a texture using OpenGL primitives.
Please let us know if you need help setting up a build environment for building FlightGear from source. Make sure to check out the wiki for additional help.