Sometimes, not all, my project, Chakra, will build up an unreal amount of lag until I have less than 1 FPS. The thing is, it only seems to happen when I have the arrow keys or WASD keys pressed for movement. It happens fairly quickly in terms of “building” up the lag. I would say the transition takes about 2 seconds from smooth to awful. Also, it only happens sometimes. 2 in 5 times that I visit the project is when I experience the phenomena.

Downgrade your adobe flash player to 11.7

ClayChips wrote:

Downgrade your adobe flash player to 11.7

Last time I tried that, it crashed my hard drive. I don't know what I did wrong. I uninstalled the previous version and everything. I would rather not go that route.

For me, the problem appears to be related to how much other tabs and windows I have open. I have tried to correlate to any specific program, or the exact number of tabs yet.

This is a common problem when running Scratch projects that are more process-heavy, and so end up taking more than the Scratch-standard 1/30th second loop time for each iteration of a loop, or each ‘frame’ of the game. (And having lots of other tabs open, or any other programs running, that may be sucking up CPU to some degree, will also have an impact on this).

I find Firefox doesn't suffer from the problem as much as Safari - and especially as much as Chrome, which seems to be very bad. It's become worse recently with the new version of Flash, in particular because applyng effects to a sprite's costume (colour/ghost/brightness/etc.) appears to now be much more intensive than it was before - for some some unknown reason.

I hear on Windows that (more recent) IE also doesn't suffer from the problem.

The best way to tackle it for now is to make sure that you're not doing anything unnecessarily in your scripts. In particular, any changes to the costume (setting size/rotation/point-in-direction/effects/costume). Every place where you use such costume-changing blocks, you should ensure you do not use the block if the costume is already set the way you want.

For example, you should not do the following (and I see this kind of thing a lot):

forever
if some-variable-check then
set size to somesize
else
set size to othersize

Instead you should at least have a check if the size needs changing before you change it:

forever
if some-variable-check then
if not(size=somesize) then
set size to somesize
else
if not(size=othersize) then
set size to othersize


Better still would be to have a broadcast that's triggered only when the variable that's being checked actually changes. So somewhere in the scripts some-variable gets changed:

set some-variable to somevalue
broadcast “change size”

And then:

when I receive “change size”
if some-variable-check then
set size to somesize
else
set size to othersize

If you avoid continuous changing of size/effect/costume/rotation/point-in-direction then you'll find it makes your scripts more efficient, which in turn should help with the key lag problem.

Hope that helps!

DadOfMrLog wrote:

This is a common problem when running Scratch projects that are more process-heavy, and so end up taking more than the Scratch-standard 1/30th second loop time for each iteration of a loop, or each ‘frame’ of the game. (And having lots of other tabs open, or any other programs running, that may be sucking up CPU to some degree, will also have an impact on this).
…

I will make my project more efficient based on your methods mentioned, and report back when I've done so!

In the mean time, I must report that I have noticed that this project doesn't lag at all when using Google Chrome. It's just slower.