Without much scripts running (just a game loop), Scratch reports a fps of over 30, usually 1000 or infinity. In cases like this I've just added a

wait () secs

after the tick block to “lower” the framerate a bit. My question is: is this the best way of going about it? Thanks!

you could use broadcast recursion

Zerofile wrote:

you could use broadcast recursion

what's that?

Kami-ko wrote:

Zerofile wrote:

you could use broadcast recursion

what's that?

I presume they mean something like this:

when I receive [foo v]
...
broadcast [foo v]

which works because broadcasts force a 1 frame delay. I personally don't recommend this as infinite recursion will (very slowly) eat up all of the user's memory.

If you need to force a 1 frame delay, the solution you have is probably the best one - although anything that touches the screen will also cause a delay so that the updated screen can be shown (except on Turbo Mode). This means, for example, that moving a sprite, creating clones, using the pen, etc. will all make it wait 1 frame so that the updated screen is seen by the user. Even a block that seemingly does nothing (such as moving 0 steps) will cause a delay, so forcing one shouldn't be necessary once you add code to show the player, sprites, etc.

Flowermanvista wrote:

Kami-ko wrote:

Zerofile wrote:

you could use broadcast recursion

what's that?

I presume they mean something like this:

when I receive [foo v]
...
broadcast [foo v]

which works because broadcasts force a 1 frame delay. I personally don't recommend this as infinite recursion will (very slowly) eat up all of the user's memory.

If you need to force a 1 frame delay, the solution you have is probably the best one - although anything that touches the screen will also cause a delay so that the updated screen can be shown (except on Turbo Mode). This means, for example, that moving a sprite, creating clones, using the pen, etc. will all make it wait 1 frame so that the updated screen is seen by the user. Even a block that seemingly does nothing (such as moving 0 steps) will cause a delay, so forcing one shouldn't be necessary once you add code to show the player, sprites, etc.

I'm just trying to check If my current strategy to make delta greater than 0; not wait a frame.

Flowermanvista wrote:

Kami-ko wrote:

Zerofile wrote:

you could use broadcast recursion

what's that?

I presume they mean something like this:

when I receive [foo v]
...
broadcast [foo v]

which works because broadcasts force a 1 frame delay. I personally don't recommend this as infinite recursion will (very slowly) eat up all of the user's memory.

~snip~
.

What will eat memory is putting two broadcasts, or a broadcast and wait.

With only one broadcast it will briefly run the two scripts at once and terminate the predecessor. So the script won't eat up memory

Zerofile wrote:

Flowermanvista wrote:

Kami-ko wrote:

Zerofile wrote:

you could use broadcast recursion

what's that?

I presume they mean something like this:

when I receive [foo v]
...
broadcast [foo v]

which works because broadcasts force a 1 frame delay. I personally don't recommend this as infinite recursion will (very slowly) eat up all of the user's memory.

~snip~
.

What will eat memory is putting two broadcasts, or a broadcast and wait.

With only one broadcast it will briefly run the two scripts at once and terminate the predecessor. So the script won't eat up memory

Huh, neat. TIL.