Added support for seeking (forwards only) - in ZlibAbstractIStreambuf, added
seekoff().
Also disabled assert that checked that we reach EOF compressed data at same
time as EOF uncompressed data; was breaking things when using embedded
compressed streams within fgtape recording.
Added ZLibCompressionFormat::ZLIB_RAW, uses windowBits=-15, for zlib compressed
streams without header or trailer.
Fixed clang build error with std::min().
- Add an Effect to stars and planets so they don't disappear when not using the fixed-pipeline.
- Allow usage of the shadow mapping related uniforms in 'quad' passes as well.
- Add extra buffer formats (some of them only work under the core profile).
- Better handling of mipmapping in the Compositor.
Attempt to narrow down the source of some fatal exceptions we see
on Senty, which occur during init/startup. All these blocks re-throw
so user behaviour is unchanged, but we’ll log the name of the subsytem.
Previously, by observation comparing actual vegetation density
on Medium, WS30 had many more trees than WS20.
This adjusts the base vegetation density down to match WS20.
Note that at High and Very High densities, there is still a disparity
that needs to be addressed.
Previously, reading LINE_FEATURE_LIST/AREA_FEATURE_LIST/COASTLINE_LIST
files were not read with the .stg file, but deferred into the
DelayLoadReadFileCallback. When the the Callback was executed, the
files were read and appropriate terrain tiles dirtied for regeneration.
However, re-generating dirtied tiles caused significant frame pauses
and was disabled in commit
deb802f74a
This meant that the Line/Area/Coastline features would only be rendered
when the next LoD tile was generated. Which created a race condition
on startup for the tile the user starts on, between the
DelayLoadReadFileCallback and the tile itself.
This commit reads these files at the same time as the initial terrain
so that the VPB has all the data required when the tile is initially
rendered. The downside is that line data is read for every tile,
even if it is far away. As the line data is stored as a series of
lat/lon floats, this is assumed to be OK.
An alternative would be to re-instate the Visitor, and instead
of dirtying existing terrain, generate the roads, and flag them to
the UpdateVisitor to add to the terrain node.
We now default to not calling parent nodes' listeners when a node's value
changes.
This avoid overheads introduced by recent addition of locking - walking up the
parent nodes needs to lock/unlock at each step, and was previously happening
whenever any node in the entire tree had its value changed, causing noticable
slowdown.
Node creation/removal still calls parent nodes' listeners as before.
If a node has new attribute VALUE_CHANGED_UP set, we do call its parent node's
listeners.
New SGPropertyNode::Attribute's VALUE_CHANGED_UP and VALUE_CHANGED_DOWN:
VALUE_CHANGED_UP: if set, when fireValueChanged() is called we also call
our parent node's fireValueChanged().
VALUE_CHANGED_DOWN: if set, new and existing child nodes have their
VALUE_CHANGED_UP and VALUE_CHANGED_DOWN attributes set.
Once set, these attributes cannot be cleared (because to correctly handle
this would require reference counting).
SGPropertyLockControl(): added parent_listeners arg. If true, we always call
parent node's fireValueChanged() when a node value changes; this restores
previous property system behaviour. Default is false.
Extra overall timing diagnostics.
Don't set node->_parent to null before calling
SGPropertyNodeImpl::fireChildRemoved().
This fixes problem with Jaguar-GR1 HUD.
[Should probably set node->_parent to null before returning, but previous
(non-locked) code didn't do this, and it would require acquiring mutex.
Previously blank lines in the various .txt LIST files
created spurious error logging. This commit does some
simple length checking and ignore blank lines rather than
complaining (and then ignoring).
Added runtime control of property locking active, and lock contention
diagnostics; new SGPropertyLockControl() allows associated property nodes to be
registered.
Added code to measure time spent locking/unlocking; disabled via preprocesor by
default because gives small decrease in fps even when disabled at runtime.
If SG_PROPS_UNTHREADSAFE is defined we defer to the old property code at build
time (requires old files to be available as props-unsafe.{hxx,cxx}). This
facility will hopefully be be removed at some point, but for now makes it
easier to compare before/after speed.
Added a std::shared_mutex to SGPropertyNode and changed all props code to use
shared or exclusive locks as necessary whenever reading/writing data.
SG_PROPERTY_LOCKING=0 or 1 can be used to control whether locking is
active. Default is 1.
SG_PROPERTY_LOCKING_VERBOSE=0 or 1 can be used to cause diagnostics to be
generated if we get lock contention. Default is 0.
Removed most of the inline implementation code in props.hxx - now that we use
locking, nearly all calls eventually end up in props.cxx in order to take out
a lock so there's no point inlining. For template code this also means that we
now explicitly instantiate / specialise in props.cxx.
Reformateed props.hxx to use consistent indentation. Also condensed identical
comments for related methods such as getBoolValue(), getIntValue() etc, which
results in more readable visual grouping.
Much of the internal implementation code for SGPropertyNode is now in the form
of static methods in a new SGPropertyNodeImpl class in props.cxx. This class is
marked as a friend of SGPropertyNode in props.hxx so these methods can access
all SGPropertyNode internal data without being declared in props.hxx. So one
can change implementation code without recompiling everything.
Removed TEST_READ and TEST_WRITE macros.
Removed SGPropertyNode::MAX_STRING_LEN - was only used in compare_strings() and
it is unnecessary.
It looks like assigning an Effect to the geode containing the osgText is
enough and there aren't any conflicts with OSG own shaders. This might
change in the future if the switch to the core profile happens.
The text shaders also rely on fixed pipeline features like
gl_FrontColor. This is because aircraft developers are used to using
material animations to change the text color.
