980
edits
User:Callahanp: Difference between revisions
Jump to navigation
Jump to search
Getting it together
No edit summary |
(Getting it together) |
||
| Line 1: | Line 1: | ||
The problem with FlightGear is its size, complexity, and the lack of a detailed guide to exploring that complexity. Several factors contribute to that complexity. Understanding FlightGear requires knowledge of many applicaiton domains, C++, an internal scripting language, a global data store, application features driven by XML or scripts, network protocols and data formats, some custom, some obscure and from the era of mainframe computers. | |||
I'll examine each of these complexity realms with a view to providing a guideline for new FlightGear developers, me for instance, with path to follow leading to regular contributions to the FlightGear C++, Nasal and XML codebases. | |||
First, the application uses C++. Second, Flight Simulation involves numerous application domains. Among them are aerodynamics, graphics, geography, geodesy, environment, navigation, networks, audio, video, and human languages. FlightGear addresses all of them and more. Next, in addition to the complexity introduced by C++ and the application domains, there's Nasal. Finally to tie it all togehter, loosely, the property tree. a global object, with individual data items of a key-value store actually stored in a tree because they are conceptually related. The property tree introduced compexity because items in it are not "owned", they're simply created at some point, in either C++, XML processing or Nasal and used wherever the data item is "needed". Connecting the dots through all the code based on identifying individual properties is not all that easy. | |||
with | |||
It's not clear from existing documentation the central role of Nasal scripting in the simulation. It's not just C++, Nasal, and the interface between them, understood as computer languages. Knowing the languages and interfaces themselves is vital, but even more important is understanding how scripting is used in FlightGear to create the simulation. If you are struggling as a newcomer to understand FlightGear's C++ code, understanding Nasal's role in driving parts of the simulation and the way it interacts with C++ code is probably one of the first things to do. It's what I'll be doing next. | |||
Part of understanding any body of code is to be able to identify how data flows through the application. Dataflows are usually represented as arrows representing messages flowing between parts of an application. The larger the arrow, the more data items in that flow. One of the problems with Flightgear, is that for the most part there is no visible structure for those larger arrows, and nothing to indicate where such an arrow starts and ends. Anything can add a data item to the property tree, and any code can access it, but nothing is keeping track of what added the item and what wants to read it, update it or destroy it. There's nothing written into the code to connect the individual items to a specific data flow. the position in the hierarchy of properties represented as a path gives you a clue, but it's not usually enough to pin things down. IDEs are great at connecting elements of code to their definitions and usage, but when we use a data store like the property tree, the connection can't be found by the IDE. These data flows through the property tree mechanisms are a real part of the Flighgear Applicaiton, but we have no easy way to visualise them. Any visualization is constructed over time by developers experiences examining and stepping through code. | |||
th Radon. Nvidia or Intel graphicson recent or older or less powerful graphics | |||
[http://wiki.flightgear.org/User:Callahanp/goals What's up with Pat] | [http://wiki.flightgear.org/User:Callahanp/goals What's up with Pat] | ||