osgXR 0.5.0 broke the API slightly, so update VRManager to use the new
enumeration names and update the required osgXR version for when using a
system version of osgXR.
Signed-off-by: James Hogan <james@albanarts.com>
Update 3rdparty/osgXR to version 0.5.0, which primarily gets us build
fixes for Windows. Unfortunately one of them requires an API breakage to
avoid some apparent preprocessor namespace pollution on Windows, which
will require minor source modification in FlightGear (left to the next
commit). The ABI is unchanged so binary compatibility is unaffected.
- Use the complete path when performing the existence check (previously,
only the directory part was used: bug in commit
8853fded29).
- Use the resolved path (SGPath instance) obtained from
FGGlobals::resolve_maybe_aircraft_path() when constructing the
SGSoundSample instance; this makes it possible to use paths starting
with the '[addon=...]' special prefix (handled by the
AddonResourceProvider) with FGSoundManager::playAudioSampleCommand(),
and therefore with the 'play-audio-sample' FGCommand.
This requires SimGear commit 8febf6b9f58e9a1919ff3 ("SGSoundSample
constructor changes").
Before this commit, if several menu entries (possibly in different
menus) had the same label after translation and latin1-ization by
FGLocale::utf8toLatin1(), selecting one of them used to fire the
bindings associated to all such entries. This is because the bindings
used to be stored in an std::map whose keys were the
translated-and-latin1-ized labels.
This commit fixes the problem in the following way:
- the std::map (_bindings) is turned into an std::forward_list;
- each element of this std::forward_list references the bindings
assigned to a menu entry;
- in order to allow FGPUIMenuBar::fireItem() to find the bindings
assigned to the menu entry that triggered it,
FGPUIMenuBar::make_menu() calls puMenuBar::add_submenu() with an
additional argument ("user data") that attaches to the puObject for
each menu entry a pointer to the relevant element of _bindings.
Note: given how the menubar is created, an std::vector wouldn't be
appropriate for _bindings, because we need the pointers to its elements
to be stable when new elements are added to _bindings.
Reported by Wayne Bragg: https://sourceforge.net/p/flightgear/mailman/message/37682605/
FGButton::init() passes the module parameter (a non-const string
reference) straight through to FGCommonInput::read_bindings() as a const
reference.
Change the FGButton::init() signature so that module is const there too,
so that callers can pass it const string references returned by
accessors without having to make copies.
Use a quad composition layer object from osgXR 0.3.9 to make the splash
screen VR friendly. This allows the OpenXR compositor to redraw the quad
without any updates from flightgear, which is particularly helpful as
flightgear makes no attempt at a reasonable VR frame rate during
initialisation.
The quad is positioned 2 meters from the user, with an aspect ratio
matching the desktop window. The quad is blended using an
unpremultiplied alpha channel which is forced to a given alpha value by
osgXR.
The splash is effectively already rendered to an FBO as non-linear SRGB,
so this is made explicit in the internal texture format, with the
rendering to the desktop window using GL_FRAMEBUFFER_SRGB to ensure it
is properly re-encoded.
Move the splash screen from the scene root to a camera group camera,
just below the GUI camera. This has a number of advantages, mainly VR
related:
- The splash FBO will only be rendered once per frame. Currently it
appears to be rendered for both near & far cameras, and with
stereoscopic rendering for both left & right (even though it splats
right across both views at the moment), so 2 or 4 times.
- It makes it possible to render the splash fullscreen on the desktop
window, while presenting it on a 3d quad in VR (possibly via an
OpenXR composition layer so the runtime can keep rendering it
smoothly while FlightGear framerate drops during loading.
Update 3rdparty/osgXR to version 0.3.9, which gets us better handling of
quirks and window closure, and the ability to create quad composition
layers which will be particularly useful for the loading screen when
flightgear isn't so good at timely frame updates.
We were not appending the video container suffix if there was already a '.' in
the name.
Part of this fix is also to simplify the code - if name_in is not "" we don't
attempt to create softlink or append /sim/video/container.
Avoid a console warning from OpenAL-soft about leaked buffers on
shutdown, by ensuring IAXClient backend does matching cleanup
for the buffers it allocates.
* Parking with point beyond parking so aircraft don't stop early
* Better approach routes (wait pattern)
* Extracting vector math from AIFlightplan
* More use of SGPositioned in ATC
The launcher diagram and navaid-search now include TACANs, using
the current NavCache encoding (DME whose name ends in TACAN). A new
‘—tacan’ option works similar to —vor etc to set position (with
optional offset).
Tuning the Tacan instrument from the command line is not yet supported,
but could be easily added.
upper_case_property causes valueChanged to fire twice, since
SGPropertyNode string storage is now immutable (std::string). This
caused double-processing of for example adding a waypoint in
the route-manager dialog. Since the InputListener already upper-cases
the string, we can simply remove the upper-case property logic.
Detects /sim/affinity-control being set to 'clear' and 'revert' and modifies
all thread affinities accordingly. Only active on Linux.
Also modified meaning of /sim/thread-cpu-affinity. Instead of true/false, we now
expect these values:
'': do nothing.
'none': tell OSG to not set up any thread affinities (same as prev
'false').
'osg': allow OSG to set up thread affinities but attempt to cancel affinity
of main thread afterwards.
This is for investigating bug 2734.
If /sim/thread-cpu-affinity is true or unset on startup, we use default
behaviour where we tell OSG to set up thread-cpu affinities.
Setting /sim/thread-cpu-affinity to false on start up results in all/most
threads being free to run on any cpu core. For example in .fgfsrc or on
command, use:
--prop:bool:/sim/thread-cpu-affinity=false
- Output files are now written in the current directory instead of being written in the aircraft folder (issue GH#337)
- A new exception TrimFailureException is now thrown when trim fails. This eases the detection of the trim failure (previously the exception message needed to be checked).
- An exception is thrown when a latitude higher than 90 degrees is supplied to a <waypoint> control element (PR GH#536)
- Fix the sign of the initial NED climb rate (property ic/gamma-deg) (PR #545)
- JSBSim now checks malformed data in <table> elements. Anything different than numbers and spaces/tabs will be rejected.
- Usage of <location> and <orientation> in engines is now officially dropped (PR #559, #561 and #563). These elements were deprecated long ago in favor of the corresponding elements <location> and <orientation> in thrusters. Therefore the code removed is no-op.
- The computation of the initial rotation rates has been fixed (Issue GH#553). Previously, the rotation rates could be initialized with extremely high values when the vehicle was spawned over the Poles. And for a given set of initial conditions, the initial rotation rates could have different values depending on the initial latitude at which the vehicle was initialized. This now fixed.
- The precision with which values are transmitted thru a socket can now be set via the attribute precision such as <output precision="8"> (PR GH#579)
- Added 2 new methods to FGFDMExec: SetOutputPath and GetOutputPath to specify the path to which the output files will be written.
- All JSBSim exceptions now inherit from JSBSim::BaseException. There still exist std::* exceptions thrown by JSBSim. Cleanup is still in progress.
- JSBSim no longer calls exit() or abort(). Exceptions are thrown instead. This gives the calling application an opportunity to gracefully recover.
