Today I have been blessed with intense lag in my upcoming project Earth Defender 2. The first signs of lag came from my intro, which uses the brightness effect. Later, when the player's ship fires its laser, the project slowed down, causing a very unpleasant experience. I will not restart this project because it is already my third and best draft. The first two were unplayable because of lag. I do have hope. The original Earth Defender also had some lag when I played it today. It was as if the framerate was dropped to a very low level. I don't know if this is just occurring in my projects or in a lot of others. So I ask these questions. How can I fix the lag? What may be causing the lag?

Edit- My computer is brand new. I got it for Christmas.

Lag seems to happen the more forever loops or clones are in your projects. Try to use the smallest amount of those as possible. Also, make sure to compact your code by shortening it as much as possible.
If your project is still lagging after that, either it is a gigantic project or your computer isn't good.

UndeadSorcerer wrote:

Today I have been blessed with intense lag in my upcoming project Earth Defender 2. The first signs of lag came from my intro, which uses the brightness effect. Later, when the player's ship fires its laser, the project slowed down, causing a very unpleasant experience. I will not restart this project because it is already my third and best draft. The first two were unplayable because of lag. I do have hope. The original Earth Defender also had some lag when I played it today. It was as if the framerate was dropped to a very low level. I don't know if this is just occurring in my projects or in a lot of others. So I ask these questions. How can I fix the lag? What may be causing the lag?

Color and pixelate effects will cause lag. It has something to do with the stage 3d rendering system, but thelogfather would know better than me.

@everyone who think it's stage3D Brightness and ghost don't trigger Stage3D, FYI.
I'm most likely going to say that the computer you're using isn't the best in the world. If it is, then it's probably the project size (if it's the case, trim or compress sounds, use clones instead of duplicating and make sure you don't have extremely long scripts (use broadcasts if needed))

Soundtracks, Clones, forever loops and visual effects all contribute to lag (excludes ghost and brightness). Sometimes file size can contribute, only when you hit like 700+ scripts

It might be your computer, macs aren't the greatest ( they can't handle blender lol).

There are numerous common reasons for lag in a project.

TBH, the best option is to share the project and let people take a look at it – many eyes are much more likely to find the problems than us just ‘guessing’ what might be going on, based on your own vague guesses at where the problem might be…


However, here are some of the things I've seen most often cause lag (and in no particular order except as I happen to remember them offhand):


1) Doing things unnecessarily within loops.

For example, switching costume, changing effects, setting direction, setting size, etc. – and the reason it is unnecessary is because it already has the setting you wanted.

A simple example, with a mouse rollover effect:

forever
if <touching [mouse-pointer v]> then
set size to (120)%
set [ghost v] effect to (0)%
else
set size to (100)%
set [ghost v] effect to (30)%
end

The above script is setting the size and ghost *every time* it does a pass around the forever loop – but most of the time it is setting it to the same size and ghosting that it already has.

Scratch can handle a few such unnecessary continual changes to a few sprites without much difficulty. But if you start to have lots of clones, and you do such things with all of them, then it will really struggle.

Instead use this:

forever
set size to (100)%
set [ghost v] effect to (30)%
wait until <touching [mouse-pointer v]>
set size to (120)%
set [ghost v] effect to (0)%
wait until <not<touching [mouse-pointer v]>>
end

Now it is only setting the size and ghosting *once* for each time that the mouse pointer moves over or leaves the sprite – i.e. only when the size/ghosting actually needs to change from what it already is.

Here's a demo project that shows the slowdown in the case of continually setting the direction:
https://scratch.mit.edu/projects/41199976/


2) Using too many colour-touch tests, too often.

Whenever Scratch tests if a sprite is touching a colour, it has to look at every pixel of the costume, and check what colour is at that pixel's position on the backdrop and/or pen layer and/or other sprites.

This is quite intensive, so you should make sure you do not duplicate colour-touch tests unnecessarily.

For example, I've seen many platformer projects that contain multiple loops doing this kind of thing:

forever
if <<touching [#000000]?> and <key [up arrow v] pressed?>> then
do stuff to jump... :: grey // above ensures player is touching ground before allowing jump
end
end

forever
if <not<touching [#000000]?>> then
apply gravity here... :: grey // probably changing y position to make player 'fall'
end
end

forever
if <touching [#000000]?> then
change y by (-1) // ensure player is not 'inside' the ground
end
end

The above has *three* tests if touching the ground!

But they can all be combined into a single loop with only *one* colour-touch test – like this:

forever
if <touching [#000000]?> then
change y by (-1) // ensure player is not 'inside' the ground
if <key [up arrow v] pressed?> then
do stuff to jump... :: grey // jump can only happen if player was touching ground (i.e. as above)
end
else
apply gravity here... :: grey // probably changing y position to make player 'fall'
end
end

Better still would be if you can avoid the colour touching test(s) entirely and instead use sprite touching test(s), since they are (usually) much quicker.

Here's a demo project about that: https://scratch.mit.edu/projects/41570802/


3) Trying to start up too many clones, too often.

Many Scratchers think having clones causes lag. No, it doesn't – at least, it's not just having the clones that causes lag, but it's more often what you *do* with them (e.g. things like in the scripts above), and, quite often, if you try to create them too quickly.

However, it's true that the actual creation of clones is quite intensive. That means you shouldn't be regularly creating more than, say, four or five clones at once.

It's often said that you should be sure to delete clones when finished with them, otherwise you'll hit the 301 clone limit if you keep creating them. However, if you're regularly creating and deleting clones, then you're going to be better off *not* deleting the clones, but actually *re-using* them.

In other words, when you've finished with some clones, but you know you're going to be wanting more very soon, the best thing to do is to hide and disable the clones (i.e. stop their scripts), and then later on, instead of creating a bunch of new clones, send some kind of broadcast that ‘wakes up’ these clones. (You will probably need some kind of global var which says how many clones you want to wake up – and each clone that wakes up will decrease that var – and other global var(s) saying what sort of tasks they are to do, etc.)


4) Using some kind of “wait” within a non-refresh custom block script.

When Scratch is running a non-refresh script, there is *nothing else* allowed to run until it is finished (unless it reaches the half-second non-refresh limit first, at which point it yields and allows a single pass through any other currently active scripts).

That means if you have, for example, a “broadcast and wait” in there, it would be stuck waiting forever (well, half a second) because Scratch is not going to start the broadcast receiver scripts for that long.

Similarly, you shouldn't use “ask and wait”, nor “wait until”, nor “wait N secs”. All of these will cause horrible lag.


5) Rotating sprite while drawing with pen.

This really only applies if you're drawing things, and you're using the “turn” and/or “point in direction” blocks, along with “move N steps”, to draw lines.

If you're going to do this, then it's worth realising that every time you change the direction, Scratch has to rotate the sprite's costume, which means it has to effectively redraw it at the new angle. –And that takes time.

What you should do instead, while drawing in this way with pen, is to set the sprite's rotation style to “don't rotate”. That means Scratch does not have to work out all this rotation stuff, and it's *much* faster.

Alternatively, a blank vector costume is also very quick (since there's nothing to rotate).

Here's a demo project about that: https://scratch.mit.edu/projects/121320890/


6) Using effects on a computer which cannot switch to Stage3D mode.

Whenever a project contains an effect block (except ghost and brightness) then Scratch will try to switch into Stage3D mode so that it can use the computer's graphics card to apply those effects *way* more quickly than the CPU can.

However, there seem to be a significant number of Scratchers with computer/OS/browser/Flash that cannot recognise when their graphics card is capable of supporting Stage3D. That means they end up still trying to do these effects with CPU – *very slowly*!

For example, if you have a backdrop and you apply the colour effect to it in a loop, then that'll work pretty well with Stage3D, but if your computer cannot switch to Stage3D then it'll cause horrible lag! (I think it only manages about three or four colour switches each second.)

If your project makes heavy use of such effects then you should provide an option to switch them off. (Better still, use a Stage3D detector, and switch them off automatically if it detects there is no Stage3D.)


7) Broadcasting to clones which create more clones.

This is a pretty common mistake when working with clones – and it can often go undetected.

What happens here is that you have a broadcast receiver script in a sprite which creates a clone (or several), which then goes on to do some things. However, if there are clones still around when the broadcast is sent, then it's not only the original sprite which creates a clone, but also all the clones.

This can sometime cause an explosion of clones! And quite often you don't realise because the new bunch of clones all start off in the same place and all do the same thing – so they're right on top of each other – and the only indicator you get is when things start lagging because so many clones are getting created (see point 3 above), and/or doing things (see point 1 above).

To avoid this you have to either create the clone(s) from a different sprite (that doesn't have clones itself), or ensure there is a way to distinguish the original sprite from a clone of that sprite.

You may be able to do the latter using a costume which only the original sprite has (so you would then receive the broadcast and only create a clone if it has that costume), or using a local variable as some kind of clone identification (so the var is set to zero in the green flag script, and set to some other value in the “when I start as a clone” script).


8) Manipulating an oversized costume.

If you use the 'big costume hack' to make a costume become much larger than the stage (because you only want part of a platformer level to be visible within the project screen, for example, so you set its size to a few thousand percent), then it can cause some computers to slow down a lot if Scratch has to start manipulating the pixels for that whole costume (for example, if you try to do touching tests against it, or if you change its size/direction, etc.)

In particular, it may seem to be OK on your computer, but a low-end Windows laptop, or Chromebook, might not have the power to deal with such a large costume, and could just grind to a halt.



There are probably more common reasons for lag – and I might add them as I happen to think of them, and have some time. However, I hope that gives some places to start looking for lag problems!

Econinja wrote:

@everyone who think it's stage3D Brightness and ghost don't trigger Stage3D, FYI.
I'm most likely going to say that the computer you're using isn't the best in the world. If it is, then it's probably the project size (if it's the case, trim or compress sounds, use clones instead of duplicating and make sure you don't have extremely long scripts (use broadcasts if needed))

I didn't say ghost effect, I said pixelate effect and color effect.

The problem is resolved!
I logged back on today and went into the original Earth Defender. It didn't lag. Earth Defender 2 did. One sprite had the whirl effect. I ended up deleting that sprite. Another had rapid cloning. I deleted it. The project still lagged so I went to the player laser and removed a brightness effect from the pen. The lag stopped. Amazingly, I put the pen effect back and it still didn't lag! I believe it was the whirl effect which threw everything off.

Added number seven (broadcasting to clones that create more clones) to my list of common lag problems above.

(Yeah, I know this is resolved, but I thought it might be handy to point to the above post from some other situations…)

Very useful post!

sigsal wrote:

Very useful post!

Please don't necropost.

I have a project where 1 of the sprites has 23 costumes and it lags veryyyyy badly, it's killing the entire project including my cursor, or maybe it lags because i added

wait (0.03173913043) secs

but does

wait (0.03173913043) secs

actually lags a scratch project? i have a sprite from another project that has over 25 costumes it didn't lag,
so another issue is that there are 8 messages broadcasted when the project is run, so seems like the wait block or the messages are the cause of lag

define fix lag
clear graphic effects

when green flag clicked
forever
if <(username) = [Jay_Wenc]> then
say [I didn't put any graphic effects in the project, weird] for (2) secs
else
fix lag
end
end

My project https://scratch.mit.edu/projects/496791839/ lags on my other computer and when I run it on a another computer which is the same kind, it ran fine. no lag yet itlags on the same kind of computer. pls help

Wolfieboy09 wrote:

My project https://scratch.mit.edu/projects/496791839/ lags on my other computer and when I run it on a another computer which is the same kind, it ran fine. no lag yet itlags on the same kind of computer. pls help

the lagging computer has more files than the not-lagging one

Jay_Wenc wrote:

Wolfieboy09 wrote:

My project https://scratch.mit.edu/projects/496791839/ lags on my other computer and when I run it on a another computer which is the same kind, it ran fine. no lag yet itlags on the same kind of computer. pls help

the lagging computer has more files than the not-lagging one

That or if it is a school computer, everything that you do is sent to the server and never calculated on the device itself which can increase the FPS of your project all the way up to 30 to 31 FPS without any lag. (Sorry if you don't understand that, I hasd a hard day).