Remove use of BUILDING_TESTSUITE from headers. Where possible, move
test APIs to their own file in the test_suite dir (testApis.cxx). For
some others, add them to a special list of ‘sources which depend on
the build mode’. This will hopefully go away with some further
refactoring.
Overview:
Previously Flightgear always used a single osgViewer::Viewer(), which
inherits from both osgViewer::ViewerBase and osgViewer::View, giving a
single view window.
If CompositeViewer is enabled, we instead use a osgViewer::CompositeViewer
which contains a list of osgViewer::View's. Each of these View's can have
its own eye position, so we can have multiple different views of the same
scene.
Enable at runtime with: --composite-viewer=1
Changes to allow use of osgViewer::CompositeViewer:
Previously FGRenderer had this method:
osgViewer::Viewer* getViewer();
This has been replaced by these two new methods:
osgViewer::ViewerBase* getViewerBase();
osgViewer::View* getView();
If CompositeViewer is not enabled (the default), the actual runtime state
is unchanged, and getViewerBase() and getView() both return a pointer to
the singleton osgViewer::Viewer() object.
If CompositeViewer is enabled, getViewerBase() returns a pointer to a
singleton osgViewer::CompositeViewer object, and getView() returns a
pointer to the first osgViewer::View in the osgViewer::CompositeViewer's
list.
The other significant change to FGRenderer() is the new method:
osg::FrameStamp* getFrameStamp()
If CompositeViewer is not enabled, this simply returns
getView()->getFrameStamp(). If CompositeViewer is enabled it returns
getViewerBase()->getFrameStamp(). It is important that code that previously
called getView()->getFrameStamp() is changed to use the new method, because
when CompositeViewer is enabled individual osgViewer::View's appear to
return an osg::FrameStamp with zero frame number).
All code that uses FGRenderer has been patched up to use the new methods so
that things work as before regardless of whether CompositeViewer is enabled
or not.
We make FGRenderer::update() call SviewUpdate() which updates any extra
views.
Extra view windows:
If CompositeViewer is enabled, one can create top-level extra view windows
by calling SviewCreate(). See src/Viewer/sview.hxx for details.
Each extra view window has its own simgear::compositor::Compositor
instance.
Currently SviewCreate() can create extra view windows that clone the
current view, or view from one point to another (e.g. from one multiplayer
aircraft to the user's aircradt) or keep two aircraft in view, one at a
fixed distance in the foreground.
SviewCreate() can be called from nasal via new nasal commands "view-clone",
"view-last-pair", "view-last-pair-double" and "view-push". Associated
changes to fgdata gives access to these via the View menu. The "view-push"
command tags the current view for later use by "view-last-pair" and
"view-last-pair-double".
Extra view windows created by SviewCreate() use a new view system called
Sview, which allows views to be constructed at runtime instead of being
hard-coded in *-set.xml files. This is work in progress and views aren't
all fully implemented. For example Pilot view gets things slightly wrong
with large roll values, Tower View AGL is not implemented, and we don't
implement damping. See top of src/Viewer/sview.cxx for an overview.
OpenSceneGraph-3.4 issues:
OSG-3.4's event handling seems to be incorrect with CompositeViewer -
events get sent for the wrong window which causes issues with resize and
closing. It doesn't seem to be possible to work around this, so closing
extra view windows can end up closing the main window for example.
OSG-3.6 seems to fix the problems.
We warn if CompositeViewer is enabled and OpenSceneGraph is 3.4.
Both the route-path cade and the RNAV code were using some bad logic
to compute the intersection point. All fixed now, but requires a
new helper in Simgear.
Avoid encoding test-data as strings, since this exceeds MSVC limits
on string literals, and tests don’t need to be relocatable anyway,
so we can just hard-code the source location into config.h
Overhaul how transitions are stored in FlightPlan XML, and how
they’re exposed to Nasal. Simplify the Nasal access by making
‘sid_trans’ and ‘star_trans’ writeable.
Extend the unit-tests a lot to cover this, both from C++ and also
from Nasal
As part of this, overhaul the ownership of FlightPlan delegate
factories, to make it safer (use ref-counting of the factories,
and allow the factory to customise delegate clean-up behaviour)
Only the in-sim version works for now, the test-suite mode is not
implemented yet. Also the test API will evolve, but should stay close
to what CppUnit defines.
Run a test file by specifying a path to nasal-test : examples will be
added to FGData shortly.
One test so far, attempting to reproduce a bug I see with the 737.
Note these tests are skipped unless you have procedures available
and set a magic env var to find them.
Ensure changes from Nasal are picked up by delegates (such as GPS) when
they are made. Add a route-manager test which sets and exits a hold
using Nasal.
As part of this, update the test API to make it easy to run Nasal from
a test.
GPS now lets the delegate handle the sequencing behaviour, by
setting a new config property. The default GPS delegate (in Nasal)
now sets this property.
This requires a corresponding FGData update.
In the initTestGlobals() helper function, the event manager is added to the subsystem manager (both
created by the FGGlobals ctor). This allows the event manager to be destroyed via the subsystem
manager in the FGGlobals dtor.
The test_suite/helpers directory has been renamed to test_suite/FGTestApi/ and
all the fgtest namespaces renamed to FGTestApi. The helper functions are now
also placed into either a setUp or tearDown namespace depending on their
function. And a new FGTestApi::PrivateAccessor::FDM namespace has been created
for holding friend classes used to access private or protected variables or
functions from solely within the test suite.
