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.
This patch adds "elapsed time" support to the sound code.
It is now possible to define <internal>dt_play</internal> or
<internal>dt_stop</internal> instead of a propery in the <volume> and
<pitch> sections of the configuration file.
- 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.
The FlightGear patch is to take account the change in the getChildren
function that now returns a vector<SGPropertyNode_ptr>. If the
removeChild functionnality is to be added in FlightGear, all those
SGPropertyNode * floating around should be changed to
SGPropertyNode_ptr.
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).
This led to an investigation into why the ident playing didn't work anymore.
Recent changes in the sound manager broke some assumptions the radiostack
code was making. These patches should hopefully fix all that back up.
Erik, please review these changes to double check I didn't do more damage
than good. :-)
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.
* Add new trigger types: raise, fall
* Add new trigger offset parameter
* Add new volume/pitch types: inv, abs, sqrt
* Add initial support for multiple events to intervere in a single sound
(by using the same name, see the crank section of 172-sound.xml)
* Cached the volume/pitch type fucntions
(No more if's inside the loops in update())
difference between the two is this: A sample is file related and sound
is a authonomus entity. This means you can have several sounds pointing
to a single sample. In that case, just one sample is loaded into memory.
The advantage is you can play the same sample with different pitch or
volume, but with just one sample loaded into memory.
To fully support this there is a new fucntion call:
FGSimpleSound *sample = new FGSimpleSound("filename");
mgr->add(sample, "name");
should be replaced by:
FGSimpleSound *sample = mgr->add("name", "filename");
But the old behaviour is still supported with one minor change, sounds
with the same name aren't supported anymore.
Erik
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.
max(width, height) by default (easily changeable) rather than just width.
(src/GUI/gui.cxx, src/Main/main.cxx, src/Main/viewer.cxx, src/Main/viewer.hxx)
1. Enable auto-configure on more versions of auto tools. (configure.in)
2. Warnings from auto-configure tools. (src/Time/Makefile.am)
3. Typo: "the it's" -> "its". (docs-mini/README.Joystick)
4. Remove definition of FGViewer::update() that now is (or can be) pure
virtual\
. (src/Main/viewer.cxx)
5. Preferred form of function name according to comments in plib:
"not_working"\
-> "notWorking". (src/Sound/soundmgr.hxx)
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.
- automake-1.4 sets default values for INCLUDES which we can't
overwrite.
- automake-1.5 renames this to DEFAULT_INCLUDES and leaves INCLUDES
open for the developer to use.
Thus for automake-1.4 we are forced to 'append' to INCLUDES and in
automake-1.5 we can just set the value to whatever we like.
Unfortunately, the behaviors of the two versions are mutually
incompatible.
The solution I am committing now works for both versions but
automake-1.5 generates a lot of spurious warning messages that are
annoying, but not fatal.
(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.
Here's an unusual patch for FlightGear -- I've created .cvsignore
files for every source directory, to make CVS output more informative.
This is especially nice when using cvs-examine from (X)Emacs to look
for changes.
- 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.
When you tune into a station start at a "random" point in the sequence.
Sped up the words per minute to 13 to which means one sequence per about 4 secs.
This means we get through the whole sequence in about 20 seconds leaving 10
seconds of silence.
