sleeping
-
- Newbie
- Posts: 5
- Joined: Tue Oct 25, 2005 5:25 pm
- Location: U.S.A.
- Contact:
sleeping
How can i make the program sleep for less than 1 second?
If you can help me it would be greatly appreciated.
Thanks.
If you can help me it would be greatly appreciated.
Thanks.
Willi@m C.
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
on a 133Mhz is should last about 5 secs
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
DO NOT EVER use FOR/NEXT delays.. EVER!
It's a big no-no!
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.
- matt2jones
- Veteran
- Posts: 80
- Joined: Sat Feb 19, 2005 8:29 am
- Location: elsewhere
- Contact:
See the thread on TIMER DELAY CONSIDERATIONS for all sides to this argument
matt
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
http://www.disjointed.cjb.net - Short Storys
http://matt2jones.deviantart.com - Random Art
http://www.freewebs.com/matt2jones - WebComic
-
- Veteran
- Posts: 109
- Joined: Thu Feb 10, 2005 12:38 pm
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:
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)
*****
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!
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)
*****
- {Nathan}
- Veteran
- Posts: 1169
- Joined: Thu Aug 19, 2004 6:08 pm
- Location: The wetlands of central Ohio, USA
- Contact:
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 himAnonymous 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 aon a 133Mhz is should last about 5 secsCode: Select all
FOR i = 1 to 9999 next i
Yes, good point!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:The PC's system time is updated approximately 18 times per second.Code: Select all
Synch! = TIMER 'synchronize to TIMER DO Start! = TIMER LOOP WHILE Start! = Synch!
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)
*****
I always used ...
Code: Select all
DO:LOOP UNTIL TIMER<>TIMER
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.Nemesis wrote:....Yes, good point!
I always used ...Cya,Code: Select all
DO:LOOP UNTIL TIMER<>TIMER
Nemesis
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.
*****
-
- Veteran
- Posts: 1055
- Joined: Sun Jan 02, 2005 2:11 pm
- Location: At my computer
- Contact:
Haha, yeah, I've done that before,.. I beleive Z!re even gave me a death threat if I continued to use them too... ... 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.. =)Nathan1993 wrote:You should NEVER use FOR...Next loops for pauses. I have seen so many programs ruined because of that...
-Kevin (aka:Rattra)
(x.t.r.GRAPHICS)
(x.t.r.GRAPHICS)
- {Nathan}
- Veteran
- Posts: 1169
- Joined: Thu Aug 19, 2004 6:08 pm
- Location: The wetlands of central Ohio, USA
- Contact:
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
-
- Veteran
- Posts: 1055
- Joined: Sun Jan 02, 2005 2:11 pm
- Location: At my computer
- Contact:
If I'm moving something on the screen, etc., this method is very nice:
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 .. )
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$ <> ""
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 .. )
-Kevin (aka:Rattra)
(x.t.r.GRAPHICS)
(x.t.r.GRAPHICS)
Sure, I'll explain...moneo wrote: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.Nemesis wrote:....Yes, good point!
I always used ...Cya,Code: Select all
DO:LOOP UNTIL TIMER<>TIMER
Nemesis
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.
*****
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'll also test this out later and post my findings if they are different than
what I suspect will happen
Cya,
Nemesis
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."
*****
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."
*****
-
- Newbie
- Posts: 5
- Joined: Tue Oct 25, 2005 5:25 pm
- Location: U.S.A.
- Contact:
Thanx
This stuff helped guys thanks!