FlightGear high-level architecture support: Difference between revisions

Jump to navigation Jump to search

FlightGear high-level architecture support (view source)

Revision as of 20:06, 25 April 2013

2 bytes removed ,  25 April 2013
→‎Objective
(→‎Objective: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg32973.html)
Line 19: Line 19:
Although the FlightGear design fairly modular it's provided as a single binary. Everyone who wants to create a new I/O module must patch the FlightGear sources and compile the FlightGear binary from scratch. This may discourage those who want to use FlightGear as a tool and extend it in some way. Moreover, it's not always possible to include all functions in a single binary. Some functions may be mutually exclusive.
Although the FlightGear design fairly modular it's provided as a single binary. Everyone who wants to create a new I/O module must patch the FlightGear sources and compile the FlightGear binary from scratch. This may discourage those who want to use FlightGear as a tool and extend it in some way. Moreover, it's not always possible to include all functions in a single binary. Some functions may be mutually exclusive.


The plan is to use this mode as an aid to parallellize flightgear on a local machine. The basic advantage is that each federate is strictly programmed single threadad. All the thread syncronization is handled by the rti library and hidden in that thing. The trick is that each of these threads must be done in a way that you can just compile that alternatively in a single standalone binary and run the same component in a networked rti - the LinuxTag booth for example.
The plan is to use HLA/RTI as an aid to parallellize flightgear on a local machine. The basic advantage is that each federate is strictly programmed single threadad. All the thread syncronization is handled by the rti library and hidden in that thing. The trick is that each of these threads must be done in a way that you can just compile that alternatively in a single standalone binary and run the same component in a networked rti - the LinuxTag booth for example.


Basically, better HLA support will make it possible for FlightGear to be split into "components" (each running in a dedicated process or in separate thread within the main FlightGear process), making better use of multi-core architectures (SMP), while decouple the flight simulation from the "viewer" part (i.e. visualization), so that steady/reliable frame rates can be achieved (see [[FGViewer]]).
Basically, better HLA support will make it possible for FlightGear to be split into "components" (each running in a dedicated process or in separate thread within the main FlightGear process), making better use of multi-core architectures (SMP), while decouple the flight simulation from the "viewer" part (i.e. visualization), so that steady/reliable frame rates can be achieved (see [[FGViewer]]).
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/59635"

Navigation menu