Arnt Karlsen writes: > > On Sat, 08 Jan 2005 14:47:20 +0800, Ivan wrote in message > <[EMAIL PROTECTED]>: > > > G''day all. > > > > I''ve written a client that drives FG using the native-fdm I/O > > mechanism. > > > > For the ''time'' variable, I've tried entering zero, and then entering > > the value returned by (Win32's) GetTickCount() --> no difference. > > > > However, interestingly, I noticed that FG starts off at midnight (in > > its internal world time) but the time advances at a phenomenal rate. > > After a couple of minutes I actually see the sky lighten up, followed > > by the sun rising in the east. Sunset follows about 2 min later. > > > > What gives ?? > > ..a _guess_: the 32bit unix calendar ticks over sometime in 2038, > while the 32bit Wintendo calendar ticks over every 49? days, > I saw this given somewhere on the web as the reason Microsoft > used (they still do?) to recommend reboots about that often.
This is true a naive Win32 clock running of of timeGetTime() rolls over every 49 days but there are ways to prevent this although I don't believe the FlightGear clock on Windows checks for this. However Ivan's problem is one of order of magnitude SimGear / timing / timestamp.XXX is where this is spelled out in code Cheers Norman _______________________________________________ Flightgear-devel mailing list [email protected] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
