Patch to enable atc chatter (and any other arbitrary "message" audio file)
to be played at any specified volume. (Previously these messages were always
played at a hardcoded volume of 1.0)
discard the display part. The curly braces wouldn't be spoken anyway,
and the | would be spoken as "vertical bar", which is completely
useless (which is why it had been disabled in the past already).
SGPropertyNode to guarded ones. This is also done for JSBSim/JSBSim.hxx,
for which JSB had given explicit permission a while ago. I postponed that
back then, but now is the time.
Incorporating the shared ptr code:
- All scenegraph references from SimGear
- SGMaterial which already had a reference counter uses now that common
infrastructure.
- SGMatModel is now counted.
- SGSoundSample from SimGear
- And the corresponding change for the sound samples in flightgear which fixes
a latent crash if FGBeacon would evern be deleted.
Create a queue of one-off wav files. Calling layer can request the system
to play any wav file. The request is thrown at the end of a play queue.
The queue is serviced sequentially so that queued wav files will no longer
overlap. When a sample is finished playing. It is removed from the queue
and deleted from memory. The next remaining request in the queue is then
played.
* Use "const string&" rather than "string" in function calls when appropriate.
* Use "const Point3D&" instead of "Pint3D" in function calls when appropriate.
* Improved course calculation in calc_gc_course_dist()
* Safer thread handling code.
Vassilii Khachaturov:
Dont use "const Point3D&" for return types unless you're absolutely sure.
Erik Hofman:
* Use SGD_(2)PI(_[24]) as defined in simgear/constants.h rather than
calculating it by hand every time.
scene management code and organizing it within simgear. My strategy is
to identify the code I want to move, and break it's direct flightgear
dependencies. Then it will be free to move over into the simgear package.
- Moved some property specific code into simgear/props/
- Split out the condition code from fgfs/src/Main/fg_props and put it
in it's own source file in simgear/props/
- Created a scene subdirectory for scenery, model, and material property
related code.
- Moved location.[ch]xx into simgear/scene/model/
- The location and condition code had dependencies on flightgear's global
state (all the globals-> stuff, the flightgear property tree, etc.) SimGear
code can't depend on it so that data has to be passed as parameters to the
functions/methods/constructors.
- This need to pass data as function parameters had a dramatic cascading
effect throughout the FlightGear code.
New panels are loaded now
New 3D model gets loaded
Reinitialize more subsystems
Add reinit() to FGFX, sound gets reinitialized
Still a lot needs to be done though.
For sounds that play while a value is in transit, use time rather than
the number of frames to judge when to halt the sound because it will be much
more reliable on high performance systems. It currently waits 10 ms.
before stopping the sound, but you might want to fiddle it a little by
changing MAX_TRANSIT_TIME defined int fg_sound.hxx
I removed some pending random code and I also fixed a
small cosmetic glitch where dt_play was cleared before it was printed.
Curt: Erik changed the sound update intervale and I further I tweaked it.
The issue is that if we put too much into the sound buffer, then we can't react
quick enough to sounds like tire squeek that need to be synced with the visuals
and the action. We put too little into the sound buffer and we risk the
audio dropping out for moment if a frame takes longer to draw than the amount
of audio in the buffer.
- Removed some old cruft.
- Removed some support for older versions of automake which technically was
correct, but caused the newer automakes to squawk warnings during an
initial sanity check (which isn't done very intelligently.)
NOTE: this fix is technically not correct for older version of automake.
These older version use the variable "INCLUDES" internally and could have
them already set to an important value. That is why we were appending
our values to them. However, newer versions of automake don't set this
value themselves so it is an error to append to a non-existant variable.
We seem to "get away" with overwriting the value on older versions of
automake, but if you have problems, consider upgrading to at least
automake-1.5.
