Discuss Scratch

Samofnj
Scratcher
11 posts

Reduce lag by removing broadcasts??? how???

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

SuperWaffle64, Samofnj, whatever goes!!
Samofnj
Scratcher
11 posts

Reduce lag by removing broadcasts??? how???

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

SuperWaffle64, Samofnj, whatever goes!!
tazz4843
Scratcher
100+ posts

Reduce lag by removing broadcasts??? how???

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.

Give me an internet!
Suggest this project to be featured!
I'm running:
  • (2.7GHz 4core) Windows 7 Professional, Flash 30.0 (release 0)
  • (1.3GHz 4core) Windows 10 Professional, Flash 30.0 (release 0)
Want to play together in Minecraft?
  • Java: tazz4843
  • PE: garila123
Last edited by kaj (Today 00:24:48)
jorrit200
Scratcher
12 posts

Reduce lag by removing broadcasts??? how???

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

here is my scratch account

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

succeed

else
fail
end

change [smartness v] by (1)
end
Samofnj
Scratcher
11 posts

Reduce lag by removing broadcasts??? how???

Thanks! I will try to do that!

SuperWaffle64, Samofnj, whatever goes!!
Samofnj
Scratcher
11 posts

Reduce lag by removing broadcasts??? how???

But do broadcasts also increase lag??

SuperWaffle64, Samofnj, whatever goes!!
Samofnj
Scratcher
11 posts

Reduce lag by removing broadcasts??? how???

Samofnj wrote:

But do broadcasts also increase lag??
or is it the wait block code??

SuperWaffle64, Samofnj, whatever goes!!
RokCoder
Scratcher
500+ posts

Reduce lag by removing broadcasts??? how???

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.


Scratch dabbling for fun…

Samofnj
Scratcher
11 posts

Reduce lag by removing broadcasts??? how???

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

SuperWaffle64, Samofnj, whatever goes!!

Powered by DjangoBB

Standard | Mobile