Cache the parsed navigation and airport data in a binary file to reduce
startup times and memory consumption (since only referenced FGPositioned
elements are held in memory).
Data will be reimported when the mod-time of any input file is changed.
If a global file is changed (nav.dat, awy.dat, apt.dat, etc), the cache
will be completely rebuilt, which takes approximately 30 seconds on
moderate hardware. (Future work may reduce this).
The quotes form is normally only used for headers with path relative
to the including file's path, though the standard doesn't strictly
mandate this. This is consistent with the rest of sg/fg, it makes the
code's intent clearer and helps to find headers. (And it's a few
milliseconds faster, too.)
saving for beacons, but since they're surprisingly few (in nav.dat), not a
an enormous saving in real terms. The major motivation is that marker beacons
don't behave like other NavRecords for radio interaction - they have no ident,
frequency or range (in the sense that NavRecord means them).
by frequency (which makes sense), and use the FGPositioned spatial data if
required. As a result, the marker beacon list is gone (since beacons are only
searched spatially). In the process, clean up various minor things - most
notably, all the 'airport-related' navaids (ILS, GS, LOC, and the beacons) now
store a FGRunway* instead of an airport id string. This is more precise, and
saves string allocations.
const) which were previously tricky but now easy. Make it possible not to
index certain types (used for taxiways) and exclude anonymous items from
the name index. Related to this, clean up FGRunway further - remove some public
members, and fix a dumb bug of mine, where we create reciprocal entries for
taxiways.
This should make startup (slightly) quicker, and shrinks FGRunway somewhat.
Convert FGNavRecord to inherit FGPositioned. This is much more self-contained than the FGRunway change, since FGNavRecord already had good encapsulation of its state. However, it's a large diff due to moving around two nasty pieces of code - the 'align navaid with extended runway centerline' logic and the 'penalise transmitters at the opposite runway end' logic.
In general things are more readable because I've replaced the Navaid type enum, and the use of Robin's integer type codes, with switches on the FGPositioned::Type code - no more trying to recall that '6' is an outer marker in Robin's data. The creation code path is also pushed down from navdb into navrecord itself.
Attached patch + new file make FGNavRecord have a .cxx file, and a constructor w
hich allows all the parameters to be supplied. Along the way I also cleaned up t
he navrecord.hxx header, lots more header pollution has been killed.
Some long methods are no longer inline, but were all suspiciously long to meet c
ompiler inlining criteria (I'm not clear if the 'inline' keyword is advisory or
mandatory in this situation) - I don't expect this to affect performance in any
way whatsoever.
The constructor addition is to support some hacking I'm doing improving the star
tup performance of the navDB by lazily loading the data, and caching it in a mor
e efficient format than text. I'm submitting this change (and probably some othe
r small tweaks in the future) since they are worthwhile as cleanups regardless o
f how my current experiments work out.
