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

I'm experiencing too much lag, but I'm not sure if it's my slow computer or the script. Can you give me your feedback, please?

Works well on my computer. I have the same problem sometimes. 2 out of 5 computers I have access to run slower. Helps to run it in the smaller window not full screen too. Think it's more to do with the graphics card than computers calculations per second.

@Uniquename1 Thanks, that's good to know.

It's fine on my computer, too.

It's working fine on my MacBook – but that does run Scratch well, and there's not a huge amount going on in the project that would slow it down, so I'm not surprised about that.


However, I think there are a couple of things it's doing that you could avoid…

1) Clone deletion and creation.
Scratch has to work hard when creating a clone (it means copying lots of stuff in memory). And, for some reason, you delete a cloud clone, and then just create another straight away. Why not just re-use the one you already have? Also, the same for the bird clones.

2) You are performing some unnecessary operations continually (most of them are pretty inconsequential here, but worth noting for future reference).
For example, in the cat sprite: “point towards mouse-pointer” (this causes Scratch to have to ‘redraw’ the vector costume, even if it's in the same direction as already pointing), “switch costume” (when hit – again, causes Scratch to do things, even if already on the costume you're switching to).
In the birds sprite: “show” (and “hide”, though that doesn't matter), “switch costume to parrot-a2” (when hit), “next costume” followed by “switch costume” (you only have two costumes, so just a single “if… then” would suffice, with a single “switch costume” in each case), checking if beyond larger bounds (when that only needs doing if you already know it's beyond lower bounds), checking touching taco (even when you know that's impossible due to sprite being beyond lower bounds and hidden).

3) Switch order of touching taco and “Im hit=0” test in Birds sprite:
Touching is a fairly intensive operation, and Scratch can avoid doing it if ‘Im hit“ is not zero, since it knows the ”and“ block cannot then be true. (Again, this is really minor, since it’s only one clone (maybe two) that will be hit, so the rest will always be checking if touching – but it's worth knowing about for future reference.)
Also, you only have a single taco, and it's the original sprite, so you could avoid the birds doing the touching test most of the time by first checking if within a certain distance of taco (since such a distance test is way quicker than doing the touching test, and the touching test would then be avoided most of the time).

4) Testing if touching colour is much more intensive than testing touching sprite/(clones).
You want to test if ”touching Bird“, but only if it's not falling. What you could do is test if touching bird first, and only check if touching colour if that was true.
(An alternative possibility would be to have the birds test if touching cat (if bird not falling) and send a broadcast if so, which cat would pick up. You'd have to split up the scripting a bit in the cat sprite. Even better would be to have the bird only do such a touching check if it knows it's within a certain distance of the cat, like the taco touching test in the case above.)


Also, this doesn't make any difference, but why two separate blocks to set x and y instead of just using the single ”go to" block?


I wrote a post a while back about some of the most common causes of lag in Scratch. You might find some of it helpful for future reference: https://scratch.mit.edu/discuss/post/2447542/

Also, this speed-test studio might have things which are worth knowing: https://scratch.mit.edu/studios/795672/


One thing I noticed, that's an actual ‘proper problem’ with the project, is the “wait 0.05 secs” in your bird sprite…
I presume you're doing this to make the flapping animation work at a more sensible speed. However, it means that it's possible for the taco to pass right through the bird during that time. The quickest way around that would be to put the animating into a separate “when I start as a clone” script, so the original script can check if hit by taco at every frame.


Hope all that kinda makes some sense!

This game doesn't lag at all for my computer. How old is the computer you run Scratch on?

TheLogFather wrote:

However, I think there are a couple of things it's doing that you could avoid…

Wow! Your tips are amazing. There were so many things in my I didn't consider until you pointed them out. Even the changing the code from set x and set y to set x and y made a big difference (redraw the sprite only once instead of twice?). I made a lot of the changes you suggested. Thank you very much for looking through the code and sharing your insights.

EP125 wrote:

This game doesn't lag at all for my computer. How old is the computer you run Scratch on?

It's a 2015 macbook pro. The game is very jittery on chrome and slightly better on firefox and safari. I tried the game on an older linux desktop and it works fine, so there may be something weird with my macbook.

busylabs wrote:

EP125 wrote:

This game doesn't lag at all for my computer. How old is the computer you run Scratch on?

It's a 2015 macbook pro. The game is very jittery on chrome and slightly better on firefox and safari. I tried the game on an older linux desktop and it works fine, so there may be something weird with my macbook.

Uh, yes, that is strange. It's the same as my MacBook, which runs Scratch really well (better than the machines owned by many Scratchers, it seems).

I'd be interested to know what sort of timings you get for some of the projects in my speed-tests studio.

Also, this penman speed-test project gives a useful indicator of how well a machine can deal with drawing things on-screen: https://scratch.mit.edu/projects/95183023/ (I get around 160-180 on my MacBook)

busylabs wrote:

Even the changing the code from set x and set y to set x and y made a big difference (redraw the sprite only once instead of twice?).

Huh, I'm rather surprised by that…

It doesn't ‘redraw’ anything on-screen until the screen refresh, which only happens after all concurrently running scripts have reached a yield point (end of a loop, a wait of some form, or end of script).

That means there's really not much difference between doing “set x” followed by “set y” compared to “go to x,y” (unless you've got the pen down, in which case the former makes two pen strokes – one horizontal, one vertical – rather than just a single stroke going straight to the final point – and that could make a difference, performancewise).


The only reason I can think offhand that it might cause such a slowdown would be something to do with the x and y values very often being off-screen. Most of your cloud and bird sprites have my_x and my_y values which are beyond the screen bounds, so when you set x/y, Scratch checks the costume bitmap and decides that it needs to put it not where you've said (so that the sprite is still partly visible on the screen).

At some point later today, I'll have a look around the Scratch source code, and play around with this a bit, to see if asking for off-screen positions really makes such a difference…

TheLogFather wrote:

Also, this penman speed-test project gives a useful indicator of how well a machine can deal with drawing things on-screen: https://scratch.mit.edu/projects/95183023/ (I get around 160-180 on my MacBook)

I get around 100 full screen, and about 170 on the small view. I did a system update and reboot on my macbook and the game is working much better. I suspect there was something running on the background bringing down the performance.

I’m on mobile and that wasn’t laggy at all, sir I think you might wanna check your PC or computer… because if it’s running worse than a mobile device, that’s just not good.

https://scratch.mit.edu/projects/154149262/ isn’t laggy at all for me and I’m on mobile, I think you might want to check your PC because if it’s laggier than mobile then you REALLY want to check your PC