It's common to use SGTime to calculate the the Julian Date, without providing time-zone information. Don't warn in these cases, since the behaviour is fine.
Adapt the freealut code into a WAV-file reader. As a side-effect, it would now be possible to deploy WAV files compressed with gzip, since we use ZLib's gzread functions to read from disk.
Implement sleeping to an absolute timestamp
as well as sleeping for a relative time in
SGtimeStamp.
The reason for including this into SGTimeStamp
is that the timestamps internals are required to
do accurate sleeps to and absolute timestamp
for the posix timer implementation.
Have a more general timestamp implementation.
Very useful for higher accuracy timings.
Modified Files:
simgear/structure/subsystem_mgr.cxx
simgear/structure/subsystem_mgr.hxx
simgear/timing/testtimestamp.cxx simgear/timing/timestamp.cxx
simgear/timing/timestamp.hxx
pun intended) that I'm touching the time library.
Brian Schack reported that the traffic scheduler messes up the timestamps
of the atlas network output. As it turns out, the c library functions
asctime, and gmtime use a static copy of the tm struct to do the internal
formatting. Our linux port of the SGTime class, incidentally, also stored
it's master time stamp in this very same struct. Thus, formatting an
arbitrary time value, would have the unwanted side effect of time travel.
Usually, this would go unnoticed, because the actual time parameters would
be updated before any damage could be done. But unwanted side effects, as
in Brian's example could occur.
On the MSVC port this appears to not have been a problem. Since that port
used a copy of the tm struct to store it's master time stamps. Since the
MSVC code also compiles cleanly on linux, it seems to be the way to go to
use that approach. In addition, it also removes some conditional compile
directives.
I've only run a short test, but didn't see any undesirable side effects.
the MSVC and MipsPro warning stuff).
As a result of this patch, simgear/sg_traits.h can be deleted. So can SGCMath.h,
but I'll do that separately.
There is one more 'mechanical' change to come - getting rid of SG_USING_STD(X),
but I want to keep that separate from everything else. (There's another mechnica
l change, replacing <math.h> with <cmath> and so on *everywhere*, but one step a
t a time)
that interdependencies between sg libs are generally unwelcome, but
sg_exception is a rather basic part, and it's already used by xml, props,
scene, sound and, of course, structure. Since props and xml are core
libs, we can assume that sg_exceptions are available. (OK'ed by Curt)
* 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.
After much trial and tribulation, Harald came up with a fix for the bug
which has been plaguing Cygwin for a couple of weeks now.
It's only a couple of lines. I've tested it exhaustively, and it seems to
cure the problem of Cygwin failing to start.
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.
- 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.
James Turner