sleeping

If you have questions about any aspect of QBasic programming, or would like to help fellow programmers solve their problems, check out this board!

Moderators: Pete, Mods

Post Reply
qbfreak2000
Newbie
Posts: 5
Joined: Tue Oct 25, 2005 5:25 pm
Location: U.S.A.
Contact:

sleeping

Post 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.
Willi@m C.
Guest

Post 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
Z!re
Veteran
Posts: 887
Joined: Wed Aug 04, 2004 11:15 am

Post 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!


I have left this dump.
User avatar
matt2jones
Veteran
Posts: 80
Joined: Sat Feb 19, 2005 8:29 am
Location: elsewhere
Contact:

Post by matt2jones »

See the thread on TIMER DELAY CONSIDERATIONS for all sides to this argument :D

matt
Do not mistake Apathy for feeling Content.

http://www.disjointed.cjb.net - Short Storys
http://matt2jones.deviantart.com - Random Art
http://www.freewebs.com/matt2jones - WebComic
RayBritton
Veteran
Posts: 109
Joined: Thu Feb 10, 2005 12:38 pm

Post by RayBritton »

yea actually thats is a millions times better than for...next
User avatar
{Nathan}
Veteran
Posts: 1169
Joined: Thu Aug 19, 2004 6:08 pm
Location: The wetlands of central Ohio, USA
Contact:

Post 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:
Image
Z!re
Veteran
Posts: 887
Joined: Wed Aug 04, 2004 11:15 am

Post 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...
I have left this dump.
moneo
Veteran
Posts: 451
Joined: Tue Jun 28, 2005 7:00 pm
Location: Mexico City, Mexico

Post 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)
*****
User avatar
{Nathan}
Veteran
Posts: 1169
Joined: Thu Aug 19, 2004 6:08 pm
Location: The wetlands of central Ohio, USA
Contact:

Post 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:
Image
Z!re
Veteran
Posts: 887
Joined: Wed Aug 04, 2004 11:15 am

Post by Z!re »

I really dont see whats wrong with the post you coded.. care to explain?
I have left this dump.
User avatar
{Nathan}
Veteran
Posts: 1169
Joined: Thu Aug 19, 2004 6:08 pm
Location: The wetlands of central Ohio, USA
Contact:

Post by {Nathan} »

You should NEVER use FOR...Next loops for pauses. I have seen so many programs ruined because of that...
Image
Z!re
Veteran
Posts: 887
Joined: Wed Aug 04, 2004 11:15 am

Post 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..
I have left this dump.
Nemesis
Coder
Posts: 36
Joined: Mon Aug 16, 2004 12:54 pm
Location: Colorado Springs, Colorado

Post 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
moneo
Veteran
Posts: 451
Joined: Tue Jun 28, 2005 7:00 pm
Location: Mexico City, Mexico

Post 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.
*****
Rattrapmax6
Veteran
Posts: 1055
Joined: Sun Jan 02, 2005 2:11 pm
Location: At my computer
Contact:

Post 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.. =)
-Kevin (aka:Rattra)
(x.t.r.GRAPHICS)
User avatar
{Nathan}
Veteran
Posts: 1169
Joined: Thu Aug 19, 2004 6:08 pm
Location: The wetlands of central Ohio, USA
Contact:

Post 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
Image
Rattrapmax6
Veteran
Posts: 1055
Joined: Sun Jan 02, 2005 2:11 pm
Location: At my computer
Contact:

Post 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: )
-Kevin (aka:Rattra)
(x.t.r.GRAPHICS)
Nemesis
Coder
Posts: 36
Joined: Mon Aug 16, 2004 12:54 pm
Location: Colorado Springs, Colorado

Post 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
moneo
Veteran
Posts: 451
Joined: Tue Jun 28, 2005 7:00 pm
Location: Mexico City, Mexico

Post 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."
*****
qbfreak2000
Newbie
Posts: 5
Joined: Tue Oct 25, 2005 5:25 pm
Location: U.S.A.
Contact:

Thanx

Post by qbfreak2000 »

This stuff helped guys thanks!
Post Reply