Time accuracy - OS2

This is a discussion on Time accuracy - OS2 ; PM app, a ball is dropped at moment T at the top of the screen (Y=0). At moment T+1, Y will be 1. At moment T+2, Y is about 4: accelaration. For a smooth display the ball also has to ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: Time accuracy

  1. Time accuracy


    PM app, a ball is dropped at moment T at the top of the screen (Y=0).
    At moment T+1, Y will be 1. At moment T+2, Y is about 4: accelaration.
    For a smooth display the ball also has to be displayed at Y=2 and Y=3,
    so it doesn't jump from Y=1 to Y=4 (and next Y=9, Y=16, ...).

    What's the preferred way nowadays to delay each step? I don't really
    need extreme nor time-critical accuracy, "close enough" will do. I did
    think about a hires timer, but elsewere I read something like "I hope
    WarpVision isn't using the hires timer". I don't know if that remark
    made sense, I just read it.

    Is the hires timer the way to go anyway, or do I need to DosSleep() in
    thread 1 and perform some benchmark counting in thread 2, or is there
    another way to get delays smaller than DosSleep()'s lores delays?



    ---

  2. Re: Time accuracy

    In <5vLxGlQNAV5B090yn@hotmai1.com>, on 08/16/2007
    at 11:04 PM, spamgate@hotmai1.com (ML) said:

    Hi,

    >What's the preferred way nowadays to delay each step?


    Generally, you can drive the all but really fast motion with a WM_TIMER
    message.

    >I don't really
    >need extreme nor time-critical accuracy, "close enough" will do.


    What's your definition of close enough?

    >I did
    >think about a hires timer, but elsewere I read something like "I hope
    >WarpVision isn't using the hires timer".


    Don't believe everything you read. Everyone's got the right to their own
    opinion.

    >Is the hires timer the way to go anyway, or do I need to DosSleep() in
    >thread 1 and perform some benchmark counting in thread 2, or is there
    >another way to get delays smaller than DosSleep()'s lores delays?


    If you think DosSleep is a lores delay, you had better do better job of
    defining "good enough."

    Have you looked at the VAC samples that use WM_TIMER messages to see if
    they have sufficient performance for your needs?

    Steven

    --
    --------------------------------------------------------------------------------------------
    Steven Levine MR2/ICE 3.00 beta 08pre #10183
    eCS/Warp/DIY/14.103a_W4 www.scoug.com irc.ca.webbnet.info #scoug (Wed 7pm PST)
    --------------------------------------------------------------------------------------------


  3. Re: Time accuracy

    On Thu, 16 Aug 2007 23:04:57 +0200, ML wrote:

    > PM app, a ball is dropped at moment T at the top of the screen (Y=0).
    > At moment T+1, Y will be 1. At moment T+2, Y is about 4: accelaration.
    > For a smooth display the ball also has to be displayed at Y=2 and Y=3,
    > so it doesn't jump from Y=1 to Y=4 (and next Y=9, Y=16, ...).
    >
    > What's the preferred way nowadays to delay each step? I don't really
    > need extreme nor time-critical accuracy, "close enough" will do. I did
    > think about a hires timer, but elsewere I read something like "I hope
    > WarpVision isn't using the hires timer". I don't know if that remark
    > made sense, I just read it.
    >
    > Is the hires timer the way to go anyway, or do I need to DosSleep() in
    > thread 1 and perform some benchmark counting in thread 2, or is there
    > another way to get delays smaller than DosSleep()'s lores delays?


    You can't do it. OS/2 is not a real time operating system.

  4. Re: Time accuracy


    > Generally, you can drive the all but really fast motion with a
    > WM_TIMER message.


    Thanks, now I know what to look for.

    >> I don't really need extreme nor time-critical accuracy, "close
    >> enough" will do.


    > What's your definition of close enough?


    The above, and the example of a smoothly moving dropped ball. With a
    smallest possible delay of 31ms and 768 pixels to travel, it'll take
    about 24 seconds? OTOH I don't need a scientific accuracy of exactly
    1.571 second for the whole drop, approx. 1.57 second is good enough,
    also compared with at least 24 seconds.

    >> I did think about a hires timer, but elsewere I read something
    >> like "I hope WarpVision isn't using the hires timer".


    > Don't believe everything you read.


    I don't, hence my question; I also cannot recall any serious "crap"-
    related remarks w.r.t. the hires timer.

    > Have you looked at the VAC samples that use WM_TIMER messages to
    > see if they have sufficient performance for your needs?


    Not yet, but now I know what to look for w.r.t. this upcoming issue.
    The VAC sample I've picked as a starting point (PMLINES) doesn't use
    it. TFM mentions an possible accuracy of about 50 ms, which wouldn't
    be good enough (768 pixels*50 ms equals a slow-motion drop).

    So if WM_TIMER is as accurate as using DosSleep(), is the next best
    thing the hires timer, or should I perform a benchmark counting (how
    many CPU cycles are passed in tread 2 fit while thread 1 pauses for
    about 100 ms)?

    I'm not actually going to show a dropped ball, but that's basicly the
    thing I want to show smoothly and realisticly. 1.6 or 1.59 second, I
    don't think I'll care about that difference, but e.g. 768 pixels * 50
    ms (smallest possible delay unit) wouldn't work for me.



    ---

  5. Re: Time accuracy


    > You can't do it. OS/2 is not a real time operating system.


    Allright, when counting CPU cycles during X ms doesn't work good, the
    hires timer will be the only way to go when it comes to reducing the
    minimal size of each delay?

    If so, just wondering: a DOS-based Formula 1 racing game (F1GP2) is
    pretty accurate with ms-based lap times. Is it likely the lap times
    are derived from the speed and distance instead of the actual clock,
    or is a DOS-game a bad example (running under OS/2, obviously)?



    ---

  6. Re: Time accuracy

    In , on 08/17/2007
    at 01:46 AM, spamgate@hotmai1.com (ML) said:

    Hi,

    >The above, and the example of a smoothly moving dropped ball. With a
    >smallest possible delay of 31ms and 768 pixels to travel, it'll take
    >about 24 seconds? OTOH I don't need a scientific accuracy of exactly
    >1.571 second for the whole drop, approx. 1.57 second is good enough, also
    >compared with at least 24 seconds.


    This should not be a problem, unless you attempt to do this on a really
    slow 486.

    >Not yet, but now I know what to look for w.r.t. this upcoming issue. The
    >VAC sample I've picked as a starting point (PMLINES) doesn't use it.


    So?

    >TFM
    >mentions an possible accuracy of about 50 ms, which wouldn't be good
    >enough (768 pixels*50 ms equals a slow-motion drop).


    Who knows if that statement is accurate anymore? IAC, I recommend you do
    some prototyping. It's trivial to start a WM_TIMER message loop and
    measure the actual results of a request for a 1 mSec interval.

    >So if WM_TIMER is as accurate as using DosSleep(), is the next best thing
    >the hires timer, or should I perform a benchmark counting (how many CPU
    >cycles are passed in tread 2 fit while thread 1 pauses for about 100 ms)?


    You can try this, but I doubt you'll get the results you expect.

    >I'm not actually going to show a dropped ball, but that's basicly the
    >thing I want to show smoothly and realisticly. 1.6 or 1.59 second, I
    >don't think I'll care about that difference, but e.g. 768 pixels * 50 ms
    >(smallest possible delay unit) wouldn't work for me.


    I recommend you look at some working code samples and see what they can
    do. There's more to getting smooth output than just accurate counting.

    Take a look at what the fm/2 About box does and no one has complained it's
    not smooth.

    Steven

    --
    --------------------------------------------------------------------------------------------
    Steven Levine MR2/ICE 3.00 beta 08pre #10183
    eCS/Warp/DIY/14.103a_W4 www.scoug.com irc.ca.webbnet.info #scoug (Wed 7pm PST)
    --------------------------------------------------------------------------------------------


  7. Re: Time accuracy

    [A complimentary Cc of this posting was sent to
    ML
    ], who wrote in article <5vLxGlQNAV5B090yn@hotmai1.com>:
    >
    > Is the hires timer the way to go anyway, or do I need to DosSleep() in
    > thread 1 and perform some benchmark counting in thread 2, or is there
    > another way to get delays smaller than DosSleep()'s lores delays?


    Many reports I saw show that using Hires timer is asking for trouble.
    If you use "contemporary" version of OS, it would not provide higher
    granularity than DosSleep().

    DosSleep() can go down to 1ms - although not on Warp3 (8ms is the
    limit); and on older (before 5? Do not remember) levels of Warp4 you
    may need some additional bruhaha to get it going.

    Hope this helps,
    Ilya

  8. Re: Time accuracy

    ML wrote:
    >
    > I'm not actually going to show a dropped ball, but that's basicly the
    > thing I want to show smoothly and realistically. 1.6 or 1.59 second, I
    > don't think I'll care about that difference, but e.g. 768 pixels * 50
    > ms (smallest possible delay unit) wouldn't work for me.
    >

    Have you considered the refresh rate of the monitor displaying the
    result? Few monitors refresh faster than 90 Hz; LCD monitors rarely
    refresh faster than 60 Hz.
    I would think you would have more than enough time between refresh
    events to calculate and ready the next update for display.

    --
    jmm (hyphen) list (at) sohnen-moe (dot) com
    (Remove .AXSPAMGN for email)

  9. Re: Time accuracy

    ML wrote:
    > PM app, a ball is dropped at moment T at the top of the screen (Y=0).
    > At moment T+1, Y will be 1. At moment T+2, Y is about 4: accelaration.
    > For a smooth display the ball also has to be displayed at Y=2 and Y=3,
    > so it doesn't jump from Y=1 to Y=4 (and next Y=9, Y=16, ...).
    >
    > What's the preferred way nowadays to delay each step? I don't really
    > need extreme nor time-critical accuracy, "close enough" will do. I did
    > think about a hires timer, but elsewere I read something like "I hope
    > WarpVision isn't using the hires timer". I don't know if that remark
    > made sense, I just read it.
    >
    > Is the hires timer the way to go anyway, or do I need to DosSleep() in
    > thread 1 and perform some benchmark counting in thread 2, or is there
    > another way to get delays smaller than DosSleep()'s lores delays?


    For my low or medium speed timing applications, I've found the following
    works well:

    * create a thread that does the follow:
    * Sleep the defined amount of time (DosSleep(1) for fastest possible)
    * Post a wakeup semaphore for the main thread
    * Loop until you get the shutdown signal
    * DO NOTHING ELSE IN THIS THREAD!!

    * Create the necessary semaphore and data structures
    * Launch the thread
    * Set it to time critical priority for best results -- should be safe as
    long as your DosSleep is in there, and you do NOTHING else in the thread
    * Wait for the semaphore to be posted
    * Reset the semphore and get the posted count from this operation
    * You can use this posted count to decide if you are behind and need to
    skip some frames (if posted more than once, your animation is behind!)
    * Perform your animation update and loop back to waiting on the semaphore

    For anything requiring more than 15 frames per second of animation, the
    only way to do it reliably on nearly all versions of OS/2 is to
    interface with the TIMER0 device driver. By default this is set up for
    1ms timing, but you can have problems if DOS applications have the high
    res timing set for the session, or some device drivers make use of it.
    The most notorious device driver to monkey with it was the Crystal sound
    chipset drivers, but I think they eventually fixed this transgression,
    because it really hosed up the DOS support. 99.99% of OS/2 device
    drivers don't mess with it. So DOS (and Win 3.1) is the only thing that
    can cause a problem with it in reality.

    It is usually good to have support for it in there, but ALWAYS give your
    users a way to turn it off.

    I use the same 2-thread approach with the hi res timer, except I replace
    the DosSleep with the sleep operation on the hi res timer (wake after N
    ms). I've used both of these approaches for my emulation projects in
    the past and they seem to work quite well.

    --
    [Reverse the parts of the e-mail address to reply.]

+ Reply to Thread