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.]
.

Relevant Pages

  • [GIT pull] timers core for 2.6.36
    ... timers: ... +delays - Information on the various kernel delay / sleep mechanisms ... +it really need to delay in atomic context?" ... void msleep; ...
    (Linux-Kernel)
  • Re: sampling rate problem
    ... thread's data will be accessible to this thread unless you syncronize. ... Since it is unlikely that you will ever get exact timing from sleep or timer ... I had a similar problem getting accurate timer delays while measuring wind ...
    (comp.lang.java.programmer)
  • Re: Multithread operations
    ... Often this kind of problems are solved by simple disabling the timer at the beginning of the tick event and enable it again at the end. ... It sends the request, receives the answer and updates the controls. ... These delays are due to the send/receive/elaborate functions. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: What can be the cause of slower API execution ?
    ... |> delays on their computers. ... |>> Start = Timer ... Some Windows security settings? ...
    (microsoft.public.vb.general.discussion)
  • Device Drivers for Slow devices
    ... 1.So how to intoduce these delays while writing this device driver in ... Is the old forloop the only option to introduce delays in the ...
    (comp.os.vxworks)