https://scratch.mit.edu/projects/585203764/

Simply adding a wait block of 0 sec totally changed the speed. check the timer difference between clicking the flag and pressing the space key.

This “bug” is used as a trick to wait for a single frame before doing any action.

That happens because, I believe, after the wait block is done waiting, it needs to wait until the next frame to run, as Scratch likes to run scripts in a way that make it easy to make 30 FPS animations. Even if the wait block has a value of 0 seconds, it will still wait for the next frame at the end. It's not really a bug, just behavior resulting from the intended implementation of blocks.

However, if you hold the Shift key while clicking the green flag to enable turbo mode, which allows scripts to run without being limited by framerate, the wait block will be done instantly if you set it to wait for 0 seconds, but it will wait a frame if you set it any higher. Do note that you probably don't need to leave turbo mode on most of the time, I'm just telling you about it to mention the fact.

It needs to wait until 30fps before doing anything…

D-ScratchNinja wrote:

That happens because, I believe, after the wait block is done waiting, it needs to wait until the next frame to run, as Scratch likes to run scripts in a way that make it easy to make 30 FPS animations. Even if the wait block has a value of 0 seconds, it will still wait for the next frame at the end. It's not really a bug, just behavior resulting from the intended implementation of blocks.

However, if you hold the Shift key while clicking the green flag to enable turbo mode, which allows scripts to run without being limited by framerate, the wait block will be done instantly if you set it to wait for 0 seconds, but it will wait a frame if you set it any higher. Do note that you probably don't need to leave turbo mode on most of the time, I'm just telling you about it to mention the fact.

Thanks for the reply!

The results are very confusing. As in the project, two cases both have a wait block in the repeat cycle. The only difference is that there is an extra wait block at the beginning. It should not affect the following behavior (like the speed of moving, twice as different).

My guess is somehow this single block changed one of the sprite's timings of update, which leaves the two sprites ‘not synchronized’. Not sure how to solve this though, because I need to use object ID on sprites which definitely needs wait block to make sure IDs pass to event handlers properly.

Scratch runs each active script in turn until it reaches a “yield” point.
Some yield points for active scripts are: the end of a script, the end of a loop, and a wait block.
After running each active script up to a yield point, the screen is updated. This happens 30 times per second.

If you add a wait 0 inside a script, the script yields there and so will not run to the end of the loop before the screen is updated.


An interesting demo project is The Tortoise and the Hare: https://scratch.mit.edu/projects/324376904/
It also links to a fuller explanation about Scratch “yield points” in a tutorial: https://scratch.mit.edu/discuss/post/3680398/



Note also that a “run without screen refresh” custom block does not yield at the end of loops inside it, but will still yield for explicit yield blocks such as wait.

Scratch-Minion wrote:

Scratch runs each active script in turn until it reaches a “yield” point.
Some yield points for active scripts are: the end of a script, the end of a loop, and a wait block.
After running each active script up to a yield point, the screen is updated. This happens 30 times per second.

If you add a wait 0 inside a script, the script yields there and so will not run to the end of the loop before the screen is updated.


An interesting demo project is The Tortoise and the Hare: https://scratch.mit.edu/projects/324376904/
It also links to a fuller explanation about Scratch “yield points” in a tutorial: https://scratch.mit.edu/discuss/post/3680398/



Note also that a “run without screen refresh” custom block does not yield at the end of loops inside it, but will still yield for explicit yield blocks such as wait.

Thanks! This is exactly what I needed.

It would be best if events can accept parameters.