sound manager. The interface was simplified and cleaned up a bit, and I
haven't back ported these changes to the plib sound wrappers ... we could
I suppose if someone really had a problem, but I haven't seen anything so
far that would indicate the extra effort is worth it.
gcc 3.4 has changed the rules for unqualified template name lookup. This
affects SGQueue.hxx. The changes I've made are backwards compatible with
earlier gcc versions. Everything else compiles pretty much okay except for a
few warnings. The resultant executable seems a bit faster too.
points are too close together, this routine can return a course of "nan"
but the distance is valid. Someday someone who understands the math should
rewrite the gc_calc_course_dist() routine so it is more robust, but for now
it's easiest to simply check for a nan result and code around the limitation.
So as you passed through the target glide slope from low to high it would
be colored: red -> white -> small range of transition to red -> white.
Now it goes the right way so you get: red -> smooth transition to -> white.
You can tell you are getting high if you see the bottom vasi start to turn
pink ... etc. etc. hopefully just like in real life.
- SkyContext.[ch]pp needs to query the window size, but apparently doesn't
do anything with it. We can hard wire a size and the cloud code seems to
behave fine.
- SkyLight.[ch]pp depends on glut_shapes so I copied over the code so it
can access those routines locally. (The routines that are used are
simply combining calls to libGLU.a
- Added documentation for SGCloudLayer
- Updated the SGSky interface a bit to make it more sensible, flexible,
and generic. This requires a code tweak on the FlightGear side as well.
the dimensions provided.) We draw the sky dome before everything else
and draw it with depth buffer off so it really doesn't matter, but it just
makes a little more sense this way.
Updated a few doxygen comments.
the API and I don't believe we'd have any hope of running at any kind of
reasonable frame rates on a non-hardware-3d accelerated box these days anyway.
to const/no-const variants of the prop->getNode() method, the 2nd bool
argument was getting promoted to an int so it would match a method with
a const SGPropertyNode * as the first argument. But that made
it match the wrong version of prop->getNode() and things were failing.
Yikes! This is one I could have stared at for days to figure out so I'm
glad I caught on to the problem. :-)
- 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.
Could the file(), dir(), base() and extension() functions be made const member
functions. As it stands they cannot be applied to const reference/pointer
values which limits their usefulness.
Curt:
Yes.
- added a new class in simgear/misc, SGTabbedValues, which parses a
null-terminated string of data separated by tabs into fields, and
supports safe conversion into various other datatypes.
I've had to hack Simgear's configure.ac quite a bit [for Mac OS X],
using the Plib one as a reference.
The basic construct (a big switch statement based on the target
type) is nice, I think, since it moves lots of IRIX / cygwin / OS-X
specialties out of the way cleanly. Much more re-factoring of the
current tests in configure is possible if people are able to test.
curt