Everyone might want to know that even with the new clone and def blocks there can be projects that can still overtake the amount of information that scratch can handle at any time.



How can you fix that? I'm having trouble.

It depends on how you've coded everything, and what you're planning on doing. So, could I see your project or your scripts? That would help a lot.

With regards,

ErnieParke

What are your computer specifications?

The most common reason for lag I've seen in Scratch is caused by continually changing the look of a sprite in some way (costume/rotation/effect) within a loop. In particular, graphic effects are notoriously bad in certain versions of flash, and esp. with Chrome.

You should ensure that you are *not* doing something like this, for example:

forever
if (somevariable=something) then
set brightness to 50
else
set brightness to 100

That's sure-fire way to make your project lag like crazy because it is always setting the brightness at every iteration of the forever loop, even when it doesn't need to (because somevariable hasn't changed since last time it went through the loop, so the brightness is already set as required).

Instead, the way to do above is to only change the brightness when “somevariable” changes to “something” (and when it changes from “something”) - if it's in a different sprite then use a broadcast.

Any of the following will cause trouble: switch costume, point towards, point in direction, set/change __ effect, set/change size. You should only ever use these blocks to *change* a setting from what it is now (i.e. perform some sort of check to make sure it's not already set that way, or ensure it only gets changed when the condition changes).


Another cause of lag I've seen a few times is using a wait until, or broadcast-and-wait, within a custom block that has refresh disabled. Since nothing else can happen while Scratch is running a non-refresh block, it means the condition will not change, or the broadcast will never be received.


If neither of those are the case for your project, then I'd suggest you share the project and provide a link so people can take a look…

Hope that helps!

#DadOfMrLog very well explained. now i understand why one of my projects lags seriously. it uses a graphic effect. however, the variable there is constantly changing, so i guess i'll have to live with it. but this is kind of sad as it wasn't the case with 1.4

prokohtu wrote:

#DadOfMrLog very well explained. now i understand why one of my projects lags seriously. it uses a graphic effect. however, the variable there is constantly changing, so i guess i'll have to live with it. but this is kind of sad as it wasn't the case with 1.4

Yes, the graphic effect lag has to do with Adobe removing some feature which made smooth, non-laggy graphic effects. Check the Announcements section for more information.

DadOfMrLog wrote:

The most common reason for lag I've seen in Scratch is caused by continually changing the look of a sprite in some way (costume/rotation/effect) within a loop. In particular, graphic effects are notoriously bad in certain versions of flash, and esp. with Chrome.

You should ensure that you are *not* doing something like this, for example:

forever
if (somevariable=something) then
set brightness to 50
else
set brightness to 100

That's sure-fire way to make your project lag like crazy because it is always setting the brightness at every iteration of the forever loop, even when it doesn't need to (because somevariable hasn't changed since last time it went through the loop, so the brightness is already set as required).

Instead, the way to do above is to only change the brightness when “somevariable” changes to “something” (and when it changes from “something”) - if it's in a different sprite then use a broadcast.

Any of the following will cause trouble: switch costume, point towards, point in direction, set/change __ effect, set/change size. You should only ever use these blocks to *change* a setting from what it is now (i.e. perform some sort of check to make sure it's not already set that way, or ensure it only gets changed when the condition changes).


Another cause of lag I've seen a few times is using a wait until, or broadcast-and-wait, within a custom block that has refresh disabled. Since nothing else can happen while Scratch is running a non-refresh block, it means the condition will not change, or the broadcast will never be received.


If neither of those are the case for your project, then I'd suggest you share the project and provide a link so people can take a look…

Hope that helps!

I'm not doing either, but I use custom blocks that use incursion (is that the right word?), and quite a few of them.

By the way, here's a link to the project.

And by ‘incursion’ I mean:

TPAL125 wrote:

And by ‘incursion’ I mean:

You mean recursion.

drmcw wrote:

TPAL125 wrote:

And by ‘incursion’ I mean:

You mean recursion.

I'm an idiot Thanks drmcw.

Ummm, yeah… ditch the recursion, just use “repeat until…”

Also, I'd suggest you rethink your touching detection algorithm…

I didn't really follow everything you were doing with that sensing list, but instead of those block clones having a forever that checks for variable “block sense” to be “y”, how about using broadcast-and-wait from “block sense stuff” in sprite 3? And set a single touching-check variable to “n” (or whatever) just before you broadcast, and then just have the blocks (clones) receive the broadcast and set that variable to “y” if they are touching sprite 3. That way you avoid putting items into a list (which is relatively slow), and you avoid forcing it to check all through that list looking for “y”.

For the special gravity clones, have another variable that acts like the touching-check one above, and set that to some appropriate value (“u” or “l”) if they detect touching sprite 3 when they receive that broadcast. Again, you then avoid checking through the list looking for “u” or “l”.

Actually, the way you're doing the touching at the moment, it's gonna be really hard to get smooth movement from sprite 3 (the block under user control) because you're having to make a change to its position, and then wait for all of the blocks (clones) to ‘report back’ whether they're touching now. And then you have to change sprite 3 position appropriately, if touching something, and then try again. That's all going to be visible because of screen refresh at every movement - and you can't switch off screen refresh, because you're having to wait for the clones to report back, so other scripts have to be allowed to run while it's waiting…

Most platformers, written with Scratch, instead tend to do their touching checks using either a specific colour of a ‘stage’ that your player-controlled character cannot move through and so check if touching, or else have the ‘stage’ as a single (or just a few) large sprite(s) that the player-controlled character can check if touching by itself - that way all the touching checks are done within the player-controlled sprite, and you can therefore use a custom block that has screen-refresh disabled, meaning you can perform multiple checks and movements very quickly without them being seen on the screen (so no ‘wobbling’ of the sprite).

An alternative which might work in your case, if you're planning to stick with blocks (or circles also might be fairly straightforward), would be to store the x,y co-ordinates of the centre of each block (clone) in a list, and have sprite 3 check itself if touching each one by simple maths alone - and you don't even need to actually move sprite 3 to do the check. What's more, you can tell straight away just how far down or across your player-controlled sprite can actually move, so you don't even need to do a ‘search’ for the point where you're just next to the block.

Anyway, I hope that gives you some ideas to work on!

Okay, thanks! I'm on it.

@prokohtu:

prokohtu wrote:

#DadOfMrLog very well explained. now i understand why one of my projects lags seriously. it uses a graphic effect. however, the variable there is constantly changing, so i guess i'll have to live with it. but this is kind of sad as it wasn't the case with 1.4

Yes, yes you can make *lots* of changes that will help your project! (Assuming that's the one you mean.)

Firstly, you have *many* sprites that are switching costume all the time unnecessarily, even when hidden! (For example, all of the button sprites are checking if touching the mouse and changing costume for it. And look at the “drs”, “kers”, “pit”, “tyre wear”, “abu”, “gear”, “revs”, “super”, “soft”, “med”, “hard”, “aero1/2/3”, “tire indicator”, “inter”, “wet”, “weather”, and “weather change” sprites - even the number sprites don't need to change costume at *every* loop through their forever loops, and are therefore slowing it all down significantly…)

Secondly, you also have some sprites that are continuously setting ghost or brightness effect - again, unnecessarily. For example, all of your track sprites, as well as “splashes”, “drops”, “cloud” and “penalty” sprites.

It doesn't look to me like the variables are really changing the “if” conditions constantly - certainly not all of them, anyway. (The variables may be changing their values, but not that often changing the result of the “if” tests that use them.) I suspect you'll find that none of the variables are really changing the result of the “if” condition *every* time through the loop, maybe more like every few times through the loop for some of them (and a couple of the sprites - “drops” and “cloud” - don't even have any changes to the value you're setting for the effect, so they really are wasting time).

If you change the way you script these effect/costume changes, I'm quite sure you'll see a really dramatic improvement!

Let me know how you get on…