20,741
edits
FlightGear Newsletter March 2012: Difference between revisions
Jump to navigation
Jump to search
m
→Development news
No edit summary |
|||
| Line 5: | Line 5: | ||
== Development news == | == Development news == | ||
=== FlightGear and HLA (High Level Architecture) === | |||
When reading the FlightGear forums or the FlightGear developers mailing list, you'll probably have noticed the term "HLA" being brought up more and more often recently. | |||
In fact, FlightGear core developers and other contributors seem to bring it up whenever somebody asks about better FlightGear modularization, better concurrency support (i.e. using all your idle CPU power), but also better overall frame rates or a more consistent multiplayer experience and weather environment. | |||
It seems as if "HLA" is the swiss army knife to deal with many long-time FlightGear challenges. | |||
So, what is HLA after all? | |||
In short: HLA, "High Level Architecture", is an industry standard (IEEE 1516) to standardize interactions between component-based simulation architectures in a distributed setup. | |||
Now, that's a mouthful, right? | |||
Let's try to describe the thing in simpler terms: Most programs (like FlightGear) have a single large code base where all subsystems get their processing time assigned by so called "main loop" which sequentially iterates over all systems and calls their "update" routine, to give each system time to do its work (update weather, update GUI, update AI, update FDM, update sound etc). | |||
Unfortunately, this also means that every subsystem running as part of the main loop has a direct effect on the simulation frame rate, i.e. the total run time cost of each complete update iteration is determined by the time spent in each individual routine, i.e. the total update time adds up: FDM+SOUND+AI+GUI etc | |||
Whenever you add a new system, you need to add it to the program's main loop and add new source files to the code base of the program. This involves rebuilding FlightGear from source. | |||
In HLA, the general idea is to split up a large simulation into a subset of smaller simulations which are interlinked exchanging information (objects and events) to create a consistent simulation environment using a well-defined interface. | |||
Only the information that is really required will be exchanged, so the exchange of this information is the only run time footprint, each simulation is responsible to compute and update its own state. | |||
Communications between each simulation node take place using a computer network and an API (similar to CORBA). All participating simulations are being managed by a central component, called the "Run-Time Infrastructure" (RTI). | |||
The RTI monitors the overall simulation and manages the distribution of data between all individual nodes, which are called "federates". The simulation in its entirety is called a "federation" in HLA. | |||
We have started a new article and copied earlier announcements and postings to it, please see [[FlightGear HLA support (High Level Architecture)]]. | |||
=== Mailing list digest === | === Mailing list digest === | ||