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)
--------------------------------------------------------------------------------------------

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.

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



---

> 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)?



---

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)
--------------------------------------------------------------------------------------------

[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

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)

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