Re: [GD-Windows] More timer fun! (sorry for revisit!)

[Lachlan L. <da_...@ho...>]

    Hey all,

    The (admittedly hobby) project I am currently working on requires that a
reliable measure of time can be assumed (for interpolating between starting
and ending times for events). From the discussion on this list it seems like
there isn't an absolutely *infallible* way of accomplishing this feat. Each
method of timing had its own problems and so using any one seemed to doom my
app to the timebomb of "when will my timer jump/drift and add
inaccuracies?". The idea I'm throwing around at the moment is to use (on
every frame update) both QPC and timeGetTime(). I'd use QPC in general and
measure the delta from the last measurement. If the delta was above a
certain error value I'd check it against the timeGetTime() one. If the same
(or similar) delta occurs in the timeGetTime delta, I could assume that the
large delta was a result of a lock-up of some sort and trust the QPC value.
If timeGetTime doesn't give a similar delta to QPC then I'd assume it was
one of the lovely "quantum" leaps and use the timeGetTime measurement for
this frame's time.

    My question is: can I assume that timeGetTime won't suffer from the
quantum leap at the same time as the QPC (Ie, that they aren't linked)? Or
at least that the percentage of times that BOTH the QPC and timeGetTime
suffer from this leap is so low that the possibility is worth ignoring?

    Cheers,

    - Lachlan

-----Original Message-----
From: Jon Watte [mailto:hp...@mi...]
Sent: Monday, September 02, 2002 3:31 PM
To: Grills, Jeff; gam...@li...
Subject: RE: [GD-Windows] More timer fun!


> don't manifest on their development machines.  Even Tom Forsyth, whom
most
> of us would say is a reasonably intelligent programmer, had problems
with
> clock drift on non-development machines using timeGetTime().  Can
> we expect
> as much from your average run of the mill programmer?  I think not.

But now we're dealing with TIME!

There's no way for your app to tell whether QueryPerformanceCounter()
jumped forward, or whether some device driver decided to lock up the
machine for a second. There is NO DIFFERENCE at the application
programming level. Thus, these functions aren't broken (unless they
actually GO BACKWARDS, as opposed to just lagging or skipping).

Note that two computers that are not hooked up to the same physical
crystal are doomed to skew out of sync sooner or later. The description
I saw from Tom sounds to me as if there was no attempt to bring the
clocks back in sync over the network. If you don't do that, you will
lose, always. Just like a digital mixing studio (or video production
studio) Just Won't Work (tm) without a common house clock.

> MS is in the unique position to know enough about the actual hardware
to
> understand if the system has these problems with QPC, and avoid the
extra

I believe chip set vendors write drivers for their chip sets, just
like toaster vendors write drivers for their toasters. And, looking
at the varying quality of chipset drivers (and other drivers in
general), I've seen little correlation between "more compled systems"
and "more competent driver writers".

Cheers,

/ h+



-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=555


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=urceforge1&refcode1=3390
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU5