[Plib-devel] gtl: the Generalized Time Lib

[Durk T. <d.t...@ch...>]

[I'm cross posting this to both plib-devel and fgfs-devel, since I believe it
might be relevant for both

Steve Baker wrote:

> Durk Talsma wrote:

[SNIP]

>

> The code that calculates the right position of the sun, moon, and planets
> > currently pretty much intertwined with the rest of FlightGear, and one of my
> > intentions is to seperate this from the core of the simulator code.
>
> Good.
>
> > Because
> > Astronomy and time code is pretty much intertwined, I'm currently thinking of
> > reorganizing this into a single time/astromomy lib. Though I'm open to
> > including this code in plib as well, I'm not sure if this is the right place
> > for this lib to go.

Ok, I've just finished the first stab at writing a generally usable time lib,
which I gave the working title of gtl (see subject). Today, I've implemented the
first class, named Time, which handles all non-local time., ie. greenwich mean
time, UTC, julian, and Greenwich Sidereal time. It turns out pretty similar to
what Steve proposed, and consists mainly of recycled FlightGear code:

>
> I guess we have some layering here:
>
>         date + local time + lat/long position
>                        |
>                        |
>                        v
>           universal time + lat/long position
>                        |
>                        |
>                        v
>             Position of sun/moon/stars
>                and sky colours
>                        |
>                        |
>                        v
>              Correctly rendered sky
>

The exception being that I don't use local time yet. I will add this later on, in
a separate class. The idea behind this is that you can only have one intstance of
a localtime class, but multlple instances of localtime in a single program. For
instance, in a hypothetical multiplayer sessionFlightGear, player one in Amsterdam
uses a different localtime then player b). in Sydney.

The  layout I have in mind looks something like the following:

Time:  all non-local time functions: hides all the nasty details of working
             with low-level time functions in a cross-platform environment.
             Only one instance allowed per program.(1)

LocalTime: A generic class for calculating local time, from longitude and UTC.
       |-------> EarthTime:   A more sophisticated mechanism, which makes
                                                      use of the timezone
mechanism
                                                      currently in FlightGear.


Timezone:   A database containing a description of all past and current timezone
                        rules. Currently already available in a somewhat crude
form.

While shuffling stuff around today, I made an interesting discovery: In
flightgear, we currently use two functions to obtain sidereal time. A precise
method and a fast method. I already noticed before that the precise method
appeared much shorter than the cheap method, so I decided, that while I was
tearing stuff apart, It would be interesting to benchmark both functions and see
how they performed. Much to my surprise, the precise method is about 3 times
faster than the cheap one. (About 30 million iterations in 30 seconds for the
precise method vs. about 10 million interations in 30 seconds for the cheap method
both tested on an Athlon 5000 MHz, running a 2.2.14 linux kernel). Inspection of
the profiling report, however revealedthat although the cheap method was indeed
somewhat faster in itself, it calls mkgm, which turned out to be relatively slow
and  take all  of the advantage away.

Based on this, I intend to scrap the cheap sidereal time estimation altogether,
because it will also yield a much cleaner code base.

>
>
> > Eventually, I'd like to develop some code that is also suitable for use in
> > stuff like a Space Flight simulator, and this would impose an additional
> > demand on the lib. My first choice in that case would be to include the
> > Astronomy and Time code in something like Curt's SimGear lib. As said, I'm
> > open to suggestion.
>
> Yes - me too!

>
>
> What I want to avoid at all costs is introducing more dependancies into
> games that use PLIB.  If Curt's new sky code is to be in some SSG-Utils
> library then it needs to depend only on SG/SSG and (possibly) other PLIB
> components.  I don't want people to have to download SimGear in order
> to get (say) Tux_AQFH to display stars/sun/moon.

Well, euhh... I already introduced a dependancy on SimGear, since I use simgear's
contants.h file.  This is only a working solution, however. Haven't really made my
mind up about this. The same goed for the Astronomy lib. Getting that one right
and making it usable across a wide range of purposes is extremely complicated. For
example, having planets in the correct position is overkill in an arcade game and
considered extreme by some people when it comes to FlightSims (sorry Steve :-)
:-)), but needed for stuff like planetarium programs and essential for something
like a space simulator. when it comes to the latter, differences in requirements
are huge as well. Whereas a 0.5 arc minute accurarcy could be tolarable for a
simple planetarium, you'd need an accuracy of at least a few kilometers when it
comes to writings space sims. In the last category, You'd also need code to render
planets, calculate graviational interactions, etc, etc,

Regards,
Durk

(1). Footnote: While thinking of it this morning, I realized that in some extreme
situation, one could write an intergalactic space flight simulation, using
spaceships that approach the speed of light. in that case clocks would go out of
sync, and one would need multiple instances of Time. However, waking up too early
this morning, and having a slight hangover, my mind refused to go in that
direction. So until it will, there's only one instance of class Time allowed.