Convert FGRunway to be heap-based, and inherit FGPositioned. This is a large, ugly change, since FGRunway was essentially a plain struct, with no accessors or abstraction. This change adds various helpers and accessors to FGRunway, but doesn't change many places to use them - that will be a follow up series of patches. It's still a large patch, but outside of FGAirport and FGRunway, mostly mechanical search-and-replace.
An interesting part of this change is that reciprocal runways now exist as independent objects, rather than being created on the fly by the search methods. This simplifies some pieces of code that search for and iterate runways. For users who only want one 'end' of a runway, the new 'isReciprocal' predicate allows them to ignore the 'other' end. Current the only user of this is the 'ground-radar' ATC feature. If we had data on which runways are truly 'single-ended', it would now be trivial to use this in the airport loader to *not* create the reciprocal.
- this exposed a bizarre issue on Mac where dragging in <AGL/agl.h> in
extensions.hxx was pulling in all of Carbon to the global namespace
- very scary. As a result, I now need to explicitly include CoreFoundation
in fg_init.cxx.
- change SG_USING_STD(x) to using std::x
SimGear change. It changes all the SG_xxxx to be the 'real' includes, and gets
rid of many #ifdef SG_HAVE_STD_INCLUDES. As an added bonus, rather than
replacing 'SG_USING_NAMESPACE(std)' with 'using namespace std', I just fixed
the small number of places to use std:: explicitly. So we're no longer polluting
the global namespace with the entire contents of std, in many cases.
There is one more 'mechanical' change to come - getting rid of SG_USING_STD(X),
but I want to keep that separate from everything else. (There's another
mechnical change, replacing <math.h> with <cmath> and so on *everywhere*, but
one step at a time)
than tick marks, and looser (zoomed) than the other 40%. Rationale:
- this was only used in *one* tape of *one* HUD ("custom")
- it's not in the MIL-STD!
- doesn't seem very useful
- relies on integer scale values, while we now have float values in the new HUD
This feature would have had to be rewritten anyway. If someone needs it and
can come forward with a (MIL-)STD description, then it can be added to the
existing tape generator again (using a value->screen-position mapper function).
Otherwise it's simply declared dead.
(Yay, one TODO and a few FIXMEs less. ;-)
encapsulation, but a real namespace would probably be better)
- extend alignment to optionally adjust x/y, and to return absolute
l/r/b/t coordinates (as opposed to plib's relative ones!)
- implement tape gaps as per Curt's order :-)
- shuffling stuff around for fun
- add generic text adjustment and
- use it in the ladder: climb -> vert bar on the outside, numbers below line
dive -> vert bar on the inside, numbers above line
implications.
Fix the ladder so it "moves" around in the hud correctly based on alpha/beta
offset projected onto the horizon line so the horizon is always the horizon.
such a box:
_____/\_____
| Booo |
|__________|
likewise with options bottom, left, right. The size can be set via option
<marker-offset> (analogous to <tape> offsets), which describes the distance
from the base to the peak. Default: 8 px
a 8 pt font (set 8 pt in preferences.xml, too)
- fix vertical alignment of digits in label and ladder (temporary
solution -- the whole font handling needs to be reviewd and fixed)
- simplify nadir and zenith (they always want to be horizontally centered
on the ladder lines, no?)
- simplify and abstract label box drawing (no need for stippled side lines)
- align text (more) correctly in label boxes
- move variable declaration near their first use (c++ style rather than c)
- rename (zenith|nadir|hat) to enable-(zenith|nadir|hat) and make them bool
(for consistency reasons)
