So, I have a project that is soooo laggy. But has a ton of broadcasts. Is this my problem? Or something else. My only solution for broadcasts is:

when green flag clicked
wait until <(foo) = [4]>
hide

Here is the project: https://scratch.mit.edu/projects/236223171/#editor

It's just the size of the project. If you can, try to squeeze all of your forever loops in a sprite down to just 1.

lag comes wen to many blocks have to activate at the same frame… hope it helps.

forever
think [..hard thinking..]
add [idea] to [ideas v]
program
if <(smartness) > [5]> then 

  succeed

else
fail
end

change [smartness v] by (1)
end

Thanks! I will try to do that!

But do broadcasts also increase lag??

Samofnj wrote:

But do broadcasts also increase lag??

or is it the wait block code??

There are many things that can affect who effectively your code runs.

Consider if you have several forever loops running in numerous sprites. Scratch isn't multithreaded which means that every one of those active scripts is running through the interpreter every single frame. It's usually the case that most of them are waiting for something to happen, constantly checking for collisions or other such things. That's a lot of wasted CPU time. It's generally far more effective to run things from a single game loop, broadcasting and/or calling custom blocks as and when necessary.

There are also certain Scratch blocks that are very CPU intensive. Checking colour against colour, for example, is hugely expensive. I can think of very few times when there isn't a faster and better alternative to that. Or, certainly, only using it as a last resort.

Multiple start (green flag) blocks is bad programming practice for several reasons. Firstly, it generally leads to many simultaneous loops kicking off (which relates to the earlier comment). It also means you don't know which order those scripts are going to run in - that's not so much an optimisation issue as an issue that often leads to hard-to-find bugs.

Forever loops… avoid! Other than around my main game loop, it's very, very rare that these are needed. They may seem to make life easier (running a loop for every clone that detects collisions for example) but they are a huge waste of resources and CPU time.

If your code is well structured then you can easily look through it to see which scripts are running at any given time. You can add frame counters and then comment our sections that you think may affect performance to see whether you're right or not. People often come to this forum with massive projects that have no obvious code flow. Sprites and clones are running forever loops all over the place, green flag blocks exist multiple times in every sprite, code is duplicated all over the place rather than being centralised. It comes down to planning - if you can easily monitor the code flow through your game then you can easily optimise it.

If your program contains lots of calculations, make sure you're not doing the same ones over and over again. Consider this simple example -

set [var1 v] to (((a) * (b)) + (c))
set [var2 v] to (((a) * (b)) + (d))

Obviously this is a very contrived and small example which wouldn't make all that much difference but you can see that the interpreter is working to interpret the same code twice. It could be replaced with the following -

set [temp v] to ((a) * (b))
set [var1 v] to ((temp) + (c))
set [var2 v] to ((temp) + (d))

Non-refresh custom blocks should be your friend! There are caveats to using them. You should never have a forever loop running in one. It will never yield to other active scripts so “broadcast and wait”, “wait” and various other blocks can't be used. But they're a fantastic way to batch graphical updates without incurring lots of vsync waits.

There are probably many other issues that I haven't mentioned but hopefully this gives you a few starting points.

RokCoder wrote:

There are many things that can affect who effectively your code runs.

Consider if you have several forever loops running in numerous sprites. Scratch isn't multithreaded which means that every one of those active scripts is running through the interpreter every single frame. It's usually the case that most of them are waiting for something to happen, constantly checking for collisions or other such things. That's a lot of wasted CPU time. It's generally far more effective to run things from a single game loop, broadcasting and/or calling custom blocks as and when necessary.

There are also certain Scratch blocks that are very CPU intensive. Checking colour against colour, for example, is hugely expensive. I can think of very few times when there isn't a faster and better alternative to that. Or, certainly, only using it as a last resort.

Multiple start (green flag) blocks is bad programming practice for several reasons. Firstly, it generally leads to many simultaneous loops kicking off (which relates to the earlier comment). It also means you don't know which order those scripts are going to run in - that's not so much an optimisation issue as an issue that often leads to hard-to-find bugs.

Forever loops… avoid! Other than around my main game loop, it's very, very rare that these are needed. They may seem to make life easier (running a loop for every clone that detects collisions for example) but they are a huge waste of resources and CPU time.

If your code is well structured then you can easily look through it to see which scripts are running at any given time. You can add frame counters and then comment our sections that you think may affect performance to see whether you're right or not. People often come to this forum with massive projects that have no obvious code flow. Sprites and clones are running forever loops all over the place, green flag blocks exist multiple times in every sprite, code is duplicated all over the place rather than being centralised. It comes down to planning - if you can easily monitor the code flow through your game then you can easily optimise it.

If your program contains lots of calculations, make sure you're not doing the same ones over and over again. Consider this simple example -

set [var1 v] to (((a) * (b)) + (c))
set [var2 v] to (((a) * (b)) + (d))

Obviously this is a very contrived and small example which wouldn't make all that much difference but you can see that the interpreter is working to interpret the same code twice. It could be replaced with the following -

set [temp v] to ((a) * (b))
set [var1 v] to ((temp) + (c))
set [var2 v] to ((temp) + (d))

Non-refresh custom blocks should be your friend! There are caveats to using them. You should never have a forever loop running in one. It will never yield to other active scripts so “broadcast and wait”, “wait” and various other blocks can't be used. But they're a fantastic way to batch graphical updates without incurring lots of vsync waits.

There are probably many other issues that I haven't mentioned but hopefully this gives you a few starting points.

Ok, I will try

I'm pretty sure you posted more than once about this post, I'd recommend not to do that even though maybe you're really in a tight situation. I'll tell you once more, head over to your “typer” and edit out “passCODE” and uncheck the run without screen refresh. It should be fixed after it.