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.
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.
- changed FGSubsystem::update(int) to
FGSubsystem::update(delta_time_sec); the argument is now delta time
in seconds rather than milliseconds
- added FGSubsystem::suspend(), FGSubsystem::suspend(bool),
FGSubsystem::resume(), and FGSubsystem::is_suspended(), all with
default implementations; is_suspended takes account of the master
freeze as well as the subsystem's individual suspended state
- the FDMs now use the delta time argument the same as the rest of
FlightGear; formerly, main.cxx made a special case and passed a
multiloop argument
- FDMs now calculate multiloop internally instead of relying on
main.cxx
There are probably some problems -- I've done basic testing with the
major FDMs and subsystems, but we'll probably need a few weeks to
sniff out bugs.
I changed the sound code to let it use FGCondition. This changes the
code and configuration files rather drastically. Furthermore I've added
an in-transit mode which plays the sound only when the tied property is
changing.
Changes:
Code:
* Added condition support to trigger an event
* Removed the <type> section from the main event definition
(this could be done using conditions)
* Removed the abillity to use several events with the same name,
instead it is required to use conditions.
* Updated the README.xmlsound
Base package:
* Changed the configuration files accordingly.
* Changed flaps and gear to use the new in-stransit mode.
* Changed the flps.wav file so it can be looped.
* Created a new gear.wav file (whcih can be looped)
and a gear-lck.wav file for gear locking sound.
IMPORTANT:
To change existing configuration files to the new ones, it is important
to pack events with the same name together into one singel event, using
the condition specification. Also, when using special types (inverted,
flip-flop, raise or fall) these should be changed to a conditions also.
For more information, please look at
FLightGear/docs-mini/README.xmlsound and the supplied aircraft
configuration files located under FlightGear/Aircraft (espesially
c172/c172-sound.xml and c310/c310-sound.xml).
The compiler complains about too long names for instanciated templates
that result in name truncation. There are warnings but finally it ends
with a fatal errors. I found that ignoring the warning cure the
problem.
interface instead of string. This will result in a lot more
efficiency later, once I add in a simple hash table for caching
lookups, since it will avoid creating a lot of temporary string
objects. The major considerations for users will be that they cannot
use
node->getName() == "foo";
any more, and will have to use c_str() when setting a string value
from a C++ string.
individual aircraft to have different sounds (and cleaning up my code
a fair bit). The most important user-visible change is the renaming
of the /sim/sound property to /sim/sound/audible.
FDM people. FlightGear now supports an unlimited number of fuel
tanks. Also added correct fuel-flow reporting for piston engines, and
tracked new features in SimGear property support.
(i.e. multiloop). Most subsystems currently ignore the parameter, but
eventually, it will allow all subsystems to update by time rather than
by framerate.
has absolutely no bearing on actual wheel performance and has nothing to do
with the fdm. It is just a simplistic wheel spin velocity model used to
avoid subsequent squealing when a tire is bouncing, or touches down right after lifting off. If at some point tire spin is modeled by an FDM we could
transition to using real data.
- changed all sound file properties to end in /path for pathname, and
added /sound and /pitch (with current values as defaults)
- don't activate the stall horn if CAS is less than 30kt (this needs
to be refined somehow)
- declarations to support changes to cxx file
- delete table in destructor
** src/FDM/flight.cxx
- bind engine properties in FGInterface::bind, and publish properties
for all engines rather than just engine 0
** src/Main/fg_props.cxx
- removed all engine properties; now bound in FGInterface::bind
** src/Sounds/fg_fx.cxx
- support multiple engine and cranking sounds
** src/Sounds/fg_fx.hxx
- support multiple engine and cranking sounds
What was happening was that we screwed up and scheduled tiles for
(lon,lon) rather than (lon,lat) ... note the typo. This generated
bogus tile id's which the system happily accepted, put into the tile
cache system, and attempted to load. The problem was that these bogus
tile id's were negative where as all valid tile id's should be >= 0.
These negative tile id's up the logic used to remove tiles from the
cache. When identifying tiles for removal, we look for the furthest
tile away from us by starting out the furthest id at -1 and if we find
something further, we update the furthest tile id. Then at the end we
check if the furthest tile id >= 0 to see if we found anything we
could remove. However, the furthest tile id was these bogus tiles
with negative tile id's so the system always assumed there was nothing
appropriate for removal. This made it impossible to ever remove a
tile from the cache meaning it quickly filled up and no more tiles
could be loaded.
I fixed the one instance of scheduling tiles for a bogus location, and
added a sanity check so if it ever happens again we'll bomb with an
appropriate error message.
