Enzo1997 wrote:
Wait one second takes more time than 1 second...
yes, its due to lag. I'm not sure if there is a solution.
Offline
it's intentional lag. it waits for something like 0.025 at each loop end.
so the script [blocks]
<repeat( 40
<wait( 1 )secsc>
<end>
[/blocks]
would take 41 seconds instead of 40.
or something on those lines anyway
Offline
but even then, there's also a tiny lag which is different on all PCs...
Offline
LS97 wrote:
but even then, there's also a tiny lag which is different on all PCs...
And the more you get it to do, the slower it gets. Why is there that 0.025 second wait period though?
Offline
i think it's rpobably because if you make a script [blocks]
<repeat( 10 ))
<move( 2 )steps>
<end> [/blocks]
it would jump 20 pixels instantly. with the 0.02 second break, the sprite would take at least 0.25 seconds to do those 20 pixels. in fact, it takes about 0.5 to 1 seconds...
Last edited by LS97 (2010-08-14 07:00:56)
Offline
markyparky56 wrote:
LS97 wrote:
but even then, there's also a tiny lag which is different on all PCs...
And the more you get it to do, the slower it gets. Why is there that 0.025 second wait period though?
Because of what ls said and the fact it has to check how many times it still has to do it, and deduct one each time it loops.
Offline
LS97 wrote:
i think it's rpobably because if you make a script [blocks]
<repeat( 10 ))
<move( 2 )steps>
<end> [/blocks]
it would jump 20 pixels instantly. with the 0.02 second break, the sprite would take at least 0.25 seconds to do those 20 pixels. in fact, it takes about 0.5 to 1 seconds...
So its for smoothness...
Offline
LS97 wrote:
i think it's rpobably because if you make a script [blocks]
<repeat( 10 ))
<move( 2 )steps>
<end> [/blocks]
it would jump 20 pixels instantly. with the 0.02 second break, the sprite would take at least 0.25 seconds to do those 20 pixels. in fact, it takes about 0.5 to 1 seconds...
This is because loops yield to other processes after running one time through. This means that the loop is only executed once per frame, rather than all in one frame (BYOB's "atomic")
Offline
I did a few tests, and it turns out that the [forever] block is a little more than 4.7222222222222222... percent slower than realtime.
Offline