Page 1 of 1

sleeping

Posted: Tue Nov 08, 2005 9:04 am
by qbfreak2000
How can i make the program sleep for less than 1 second?
If you can help me it would be greatly appreciated.
Thanks.

Posted: Tue Nov 08, 2005 9:23 am
by Guest
use FB http://www.freebasic.net it uses 1000th's of a second

or if the program is going to be one pc then you can use a

Code: Select all

FOR i = 1 to 9999
next i
on a 133Mhz is should last about 5 secs

Posted: Tue Nov 08, 2005 10:44 am
by Z!re
DO NOT EVER use FOR/NEXT delays.. EVER!
It's a big no-no!

Code: Select all

delay! = 0.2       'seconds


' Do the actuall delay here:
tt! = timer+delay!
do
loop until timer >= tt!



Posted: Tue Nov 08, 2005 10:50 am
by matt2jones
See the thread on TIMER DELAY CONSIDERATIONS for all sides to this argument :D

matt

Posted: Tue Nov 08, 2005 10:57 am
by RayBritton
yea actually thats is a millions times better than for...next

Posted: Tue Nov 08, 2005 2:50 pm
by {Nathan}
z!re, tell us... what that a *normal* visitors ip? if so, we need to flame... er, educate him... yeah... thats it :wink:

Posted: Tue Nov 08, 2005 7:06 pm
by Z!re
Nathan1993 wrote:z!re, tell us... what that a *normal* visitors ip? if so, we need to flame... er, educate him... yeah... thats it :wink:
Educate who about what? Noone said anything out of order or wrong here...

Posted: Tue Nov 08, 2005 7:35 pm
by moneo
Just in case you're concerned with the accuracy of sampling the TIMER,
you might consider synchronizing to the TIMER before you start your actual TIMER sampling loop, using the following:

Code: Select all

Synch! = TIMER           'synchronize to TIMER
DO
  Start! = TIMER
LOOP WHILE Start! = Synch!
The PC's system time is updated approximately 18 times per second.
Therefore, it is possible that your TIMER sampling loop could begin
just before the timer is about to be incremented. In that case the
elapsed time would appear to be 1/18th second longer than the actual time.
To avoid this potential inaccuracy, the above synchonize loop waits until
a new time period has just begun. There is still a similar accuracy loss
at the end of your sampling loop. But by synchronizing at the start, the
error is limited to 1/18th second instead of twice that.
(Thanks to Ethan Winer)
*****

Posted: Wed Nov 09, 2005 2:59 pm
by {Nathan}
Anonymous wrote:use FB http://www.freebasic.net it uses 1000th's of a second

or if the program is going to be one pc then you can use a

Code: Select all

FOR i = 1 to 9999
next i
on a 133Mhz is should last about 5 secs
z1re, you are saying this is out of order? cuz if this is one of our members, me need to flame, but if this is a guest we need to learn him :lol:

Posted: Wed Nov 09, 2005 3:07 pm
by Z!re
I really dont see whats wrong with the post you coded.. care to explain?

Posted: Thu Nov 10, 2005 2:36 pm
by {Nathan}
You should NEVER use FOR...Next loops for pauses. I have seen so many programs ruined because of that...

Posted: Thu Nov 10, 2005 5:05 pm
by Z!re
Nathan1993 wrote:You should NEVER use FOR...Next loops for pauses. I have seen so many programs ruined because of that...
Yes, I already said that :P

No need to bash him anymore.. and he's a real user..

Posted: Fri Nov 11, 2005 5:43 pm
by Nemesis
moneo wrote:Just in case you're concerned with the accuracy of sampling the TIMER,
you might consider synchronizing to the TIMER before you start your actual TIMER sampling loop, using the following:

Code: Select all

Synch! = TIMER           'synchronize to TIMER
DO
  Start! = TIMER
LOOP WHILE Start! = Synch!
The PC's system time is updated approximately 18 times per second.
Therefore, it is possible that your TIMER sampling loop could begin
just before the timer is about to be incremented. In that case the
elapsed time would appear to be 1/18th second longer than the actual time.
To avoid this potential inaccuracy, the above synchonize loop waits until
a new time period has just begun. There is still a similar accuracy loss
at the end of your sampling loop. But by synchronizing at the start, the
error is limited to 1/18th second instead of twice that.
(Thanks to Ethan Winer)
*****
Yes, good point!

I always used ...

Code: Select all

DO:LOOP UNTIL TIMER<>TIMER
Cya,

Nemesis

Posted: Fri Nov 11, 2005 6:27 pm
by moneo
Nemesis wrote:....Yes, good point!

I always used ...

Code: Select all

DO:LOOP UNTIL TIMER<>TIMER
Cya,

Nemesis
I think I get the idea of your code, and it's very clever. But I have a doubt about how the code works on a fast PC. TIMER ticks of 1/18 of a second are slow. If a fast PC can access TIMER twice very fast, thus always getting the same value, it will never get a chance to be unequal and fall out of the loop.

I ran a test program on a 2.4 ghz Pentium 4 which accesses TIMER twice, like:
PRINT #2,TIMER,TIMER
Did this 10,000 times, then checked the output file. The vast majority of the times when the TIMER changed, it was the same for both values. There were a few cases when the first TIMER was unequal to the second, but sometimes it took up to 2-3 seconds to occur. What would happen on a 3+ ghz PC?

If I'm wrong, please explain. Thanks.
*****

Posted: Sun Nov 13, 2005 10:12 am
by Rattrapmax6
Nathan1993 wrote:You should NEVER use FOR...Next loops for pauses. I have seen so many programs ruined because of that...
Haha, yeah, I've done that before,.. I beleive Z!re even gave me a death threat if I continued to use them too... :lol: ... Now, several months later I'm sitting happily with a nice delay algo that is very nice on just about any computer speed.. ^_^ .. Funny how loss of life can be a great motivational tool.. =)

Posted: Sun Nov 13, 2005 12:17 pm
by {Nathan}
yeah, I used that before and then I realized it didnt work on my 2 ghz pc vs my 133mhz... haha. So I just used my programing books method for a long time... ever since really.

Code: Select all

Now! = TIMER
DO
LOOP UNTIL TIMER > Now! + 3 :REM Would delay for 3 seconds

Posted: Sun Nov 13, 2005 4:22 pm
by Rattrapmax6
If I'm moving something on the screen, etc., this method is very nice:

Code: Select all

T! = TIMER
RATE = 50'PPS
DO
    'Do Stuff
   
    'Find PPS Advancement
    F = F + 1
    IF (TIMER - T!) <> 0 THEN FPS! = F / (TIMER - T!)
    IF FPS! <> 0 THEN Advance! = RATE / FPS!
   
    'Advance cords
    PositionX = PositionX + Advance!
LOOP UNTIL INKEY$ <> ""
What this does is ratio out Main loop FPS to your Pixel Per Second(PPS), and gives you the value in which to advance your sprite. PPS can be a constant or a variable to gauge at will.

It's goal in mind is for when a loop is turning slower than your delay:
I want 50 FPS motion, but the program is turning 30FPS.
The normal time delay becomes useless there, where as a PPS advancement delay will run at 50FPS motion while the program turns at 30FPS. Do note, it also works if the program is running faster than the PPS setting,. or the same speed,. so it's very flexiable..

So far as I've seen, what ever you move is constant in speed over any machine as long as main loop speed doesn't drop below say 9FPS (Where it will become jerky),. Which in any case,. for a computer's loop to be turning that slow restricted only by processing, it's not a computer to be playing games on.. =P

(Code above was in FreeBasic, but I changed it to work in QB or at least it should .. :wink: )

Posted: Sun Nov 13, 2005 7:02 pm
by Nemesis
moneo wrote:
Nemesis wrote:....Yes, good point!

I always used ...

Code: Select all

DO:LOOP UNTIL TIMER<>TIMER
Cya,

Nemesis
I think I get the idea of your code, and it's very clever. But I have a doubt about how the code works on a fast PC. TIMER ticks of 1/18 of a second are slow. If a fast PC can access TIMER twice very fast, thus always getting the same value, it will never get a chance to be unequal and fall out of the loop.

I ran a test program on a 2.4 ghz Pentium 4 which accesses TIMER twice, like:
PRINT #2,TIMER,TIMER
Did this 10,000 times, then checked the output file. The vast majority of the times when the TIMER changed, it was the same for both values. There were a few cases when the first TIMER was unequal to the second, but sometimes it took up to 2-3 seconds to occur. What would happen on a 3+ ghz PC?

If I'm wrong, please explain. Thanks.
*****
Sure, I'll explain...

First off, I suspect when you checked the output file and seen many instances of the output of the timer values where the same was because,
the time QB was writing the values to the file the values changed, so it missed it. This testing method is faulty for that reason.
Secondly, if you think about it, the faster the CPU is the better my code would perform, and in fact, the slower the CPU is the bigger chance the computer would actually be doing other tasks and miss a timer value difference. (Kinda like how your testing code did).
Anyways, try running something like this with different processing speeds
and see the results you get...

Code: Select all

DO
 t!=TIMER
 DO:LOOP UNTIL TIMER<>TIMER
 ?ABS(TIMER-t!)
LOOP UNTIL LEN(INKEY$)
I suspect the output should be pretty consistant with 1/18 sec.
I'll also test this out later and post my findings if they are different than
what I suspect will happen :shock:

Cya,

Nemesis

Posted: Sun Nov 13, 2005 7:36 pm
by moneo
Nemesis,

Yeah, let me know the results of your testing.

You know, we're splitting hairs here. The original timer sync logic by Ethan Winer is 4 lines of code. Yours is actually 2 lines of code. If you agree that Winer's method works, and your method also works, then we are discussing saving 2 small lines of code to make it more elegant.

At this point I'm still a little doubtful of your method, and therefore not really convinced that it's worth it.

As C.J. Date of Relational Database fame once told us,
"Make things simple but not simpler."
*****

Thanx

Posted: Fri Nov 18, 2005 6:01 pm
by qbfreak2000
This stuff helped guys thanks!