Hi,

I am making a project, and it's actually rather small.

I wanted to do some cool things with it, but due to crazy lag, i sometimes can't even test the thing, much less add to it.

Please look at it and tell me if there's something I'm doing that's causing this. All the clones i am using should be deleting, so that should be it.

Projects like this and this seem to work fine.

What are your computer specifications? RAM? Processor? Monitor resolution? Also, are you on Chrome and using graphic effect blocks?

So it lags.

It's lagged from day 1. It's a nonnegotiable part of 2.0.

웃

turkey3 wrote:

What are your computer specifications? RAM? Processor? Monitor resolution? Also, are you on Chrome and using graphic effect blocks?

I am using graphic effect blocks, i am not on chrome, mozzila fire fox, i am not totally sure about the rest, but a scratcher that claims his computer is really good and fast says that this project lags really bad.

I believe that i have 2 gb of RAM, but i am not sure about the processor.

Thanks for taking notice, this is really frustrating.

To the second responder:

The problem with that is that larger projects don't lag near as bad. And i mean projects that are more than 3x this one's size.

b.u.m.p.

CAA14 wrote:

turkey3 wrote:

What are your computer specifications? RAM? Processor? Monitor resolution? Also, are you on Chrome and using graphic effect blocks?

I am using graphic effect blocks, i am not on chrome, mozzila fire fox, i am not totally sure about the rest, but a scratcher that claims his computer is really good and fast says that this project lags really bad.

I believe that i have 2 gb of RAM, but i am not sure about the processor.

Thanks for taking notice, this is really frustrating.

To the second responder:

The problem with that is that larger projects don't lag near as bad. And i mean projects that are more than 3x this one's size.

Are you on Windows? To find out your specs, go to the start menu and right click the “computer” and select “properties” (Win 7). Then tell us the specs. Usually, a Intel Core i3, i5, and i7 processor run pretty smoothly (especially i5 and up). If you have a Core 2 Duo processor, that is pretty old and can lag some, as well as an Intel Core Pentium. What you also might want to do is while the project is running hit ctrl-alt-delete, go into the task manager, and on one of the tabs there are green bar showing how much percent of your processor is being used up as well as your RAM. If you're RAM bar is at 100% or near it, that's reasonable why it might lag. I have 6 Gigs of RAM, and running a simple project filled up 2.56 Gigabytes of it. Typically, on a Scratch project, a low amount of the processor is used up but a lot of RAM.

a lot of lag can sometimes be made if you put “forever” into an atomic procedure, or you just make scratch do way too many calculations in an atomic procedure.

The specs are:

RAM: 4.00; 3.75 Available
processor: AMD Turion X2 dual-core Mobile RM-70 2.00 GHz


It's a 64 bit system.

Thanks again.

I suspect your major cause of lag, as often turns out to be the case, may well be making unnecessary changes to the look of your sprite. Either by applying effects, switching costume, rotating (including ‘point towards’), or changing size.

Here's some general advice on how a project can be made more efficient by dealing with such cases (haven't looked at the project in question, so YMMV)…


Any time you use a looks block that can potentially change the look of a sprite (see above for list of such), it is very expensive.

SPECIAL NOTE - THIS NEXT LINE IS VERY IMPORTANT - YES, I KNOW I'M WRITING IN CAPS …
Even if the looks block sets the sprite to look the same as it already is, or even if the sprite is hidden, Scratch still goes through all the (un)necessary calculations to make that change! -And it's a lot of work! (For example, if you're setting the ghost effect to 50 when it already is set to 50, or switching costume to the costume it already is set to.)


What I see very often is something along these lines:

forever
if (some-variable = somevalue) then
set ghost effect to 50
else
set ghost effect to 100

That means that every iteration of the loop it is applying a ghost effect - even if the variable it's checking has not changed.

It's somewhat unfortunate, I feel, that Scratch tends to make such style of scripting very easy, when it's so bad for performance.


A more efficient way of doing it is to at least check the setting before you reset it, where you can (e.g. if it's the size or direction there is a reporter you can use to compare against):

forever
if (some-variable = somevalue) then
if not (size=50) then
set size to 50 %
else
if not (size=100) then
set size to 100 %

For effects you don't have a reporter, so you'd have to make a (local) variable for the sprite so you can keep your own record of what the current setting is…


But ideally, you would only make the change to the look of the sprite at the same point that the variable gets changed. But if it's in a different sprite then you can't do that directly (which may well be why you put it into that forever/repeat loop to begin with…)
So, an even better way than using the extra checks shown in the forever loop above would be to send a broadcast at the point where the variable actually changes - and then make the appropriate change to the look of the sprite when the sprite receives that broadcast…

So something like this where the checked variable gets changed:

set some-variable to somevalue
broadcast “some-variable was changed”

Then receive it like this to make the change to the look:

when I receive “some-variable was changed”
if (some-variable = somevalue) then
set ghost effect to 50
else
set ghost effect to 100

In this case you have to remember to set the effect (or whatever it may be) to the desired value at the start (or send the broadcast at the start to get it set up correctly).


If you look through your projects and follow the above advice, you may well find it makes a significant difference to how well it performs…

Hope that's useful!

CAA14 wrote:

The specs are:

RAM: 4.00; 3.75 Available
processor: AMD Turion X2 dual-core Mobile RM-70 2.00 GHz


It's a 64 bit system.

Thanks again.

Oh, those are good, so it must be the graphic effects (read DadOfMrLogs post).

DadOfMrLog wrote:

I suspect your major cause of lag, as often turns out to be the case, may well be making unnecessary changes to the look of your sprite. Either by applying effects, switching costume, rotating (including ‘point towards’), or changing size.

Here's some general advice on how a project can be made more efficient by dealing with such cases (haven't looked at the project in question, so YMMV)…


Any time you use a looks block that can potentially change the look of a sprite (see above for list of such), it is very expensive.

SPECIAL NOTE - THIS NEXT LINE IS VERY IMPORTANT - YES, I KNOW I'M WRITING IN CAPS …
Even if the looks block sets the sprite to look the same as it already is, or even if the sprite is hidden, Scratch still goes through all the (un)necessary calculations to make that change! -And it's a lot of work! (For example, if you're setting the ghost effect to 50 when it already is set to 50, or switching costume to the costume it already is set to.)


What I see very often is something along these lines:

forever
if (some-variable = somevalue) then
set ghost effect to 50
else
set ghost effect to 100

That means that every iteration of the loop it is applying a ghost effect - even if the variable it's checking has not changed.

It's somewhat unfortunate, I feel, that Scratch tends to make such style of scripting very easy, when it's so bad for performance.


A more efficient way of doing it is to at least check the setting before you reset it, where you can (e.g. if it's the size or direction there is a reporter you can use to compare against):

forever
if (some-variable = somevalue) then
if not (size=50) then
set size to 50 %
else
if not (size=100) then
set size to 100 %

For effects you don't have a reporter, so you'd have to make a (local) variable for the sprite so you can keep your own record of what the current setting is…


But ideally, you would only make the change to the look of the sprite at the same point that the variable gets changed. But if it's in a different sprite then you can't do that directly (which may well be why you put it into that forever/repeat loop to begin with…)
So, an even better way than using the extra checks shown in the forever loop above would be to send a broadcast at the point where the variable actually changes - and then make the appropriate change to the look of the sprite when the sprite receives that broadcast…

So something like this where the checked variable gets changed:

set some-variable to somevalue
broadcast “some-variable was changed”

Then receive it like this to make the change to the look:

when I receive “some-variable was changed”
if (some-variable = somevalue) then
set ghost effect to 50
else
set ghost effect to 100

In this case you have to remember to set the effect (or whatever it may be) to the desired value at the start (or send the broadcast at the start to get it set up correctly).


If you look through your projects and follow the above advice, you may well find it makes a significant difference to how well it performs…

Hope that's useful!

Out of curiosity, how do you know that Scratch goes through the graphics process even when it's already set at that values?

Because when you stop it from making such (unnecessary) changes then your project runs significantly faster!

It's not that hard to check…


Start with the default two-costume scratch cat project, and make two variables (counter and time), then:

when GF clicked
set time to 0
set counter to 0
reset timer
forever
change counter by 1
if (counter>300) then
switch to costume 1
else
switch to costume 2
if (counter>600) then
set counter to 0
set time to timer
reset timer


Run above and note the values shown by the time variable - that's the time to do 600 costume changes, all but two of which were unnecessary.

Now put simple checks around costume switches:

if (costume#=2) then
switch to costume 1

and:

if (costume#=1) then
switch to costume 2

So now it's only doing the costume switch if the costume is different to what it's about to switch to.
And look at the time you get when you runt it now…

It's worse if using effects (esp. multiple) rather than costume switch…

DadOfMrLog wrote:

I suspect your major cause of lag, as often turns out to be the case, may well be making unnecessary changes to the look of your sprite. Either by applying effects, switching costume, rotating (including ‘point towards’), or changing size.

Here's some general advice on how a project can be made more efficient by dealing with such cases (haven't looked at the project in question, so YMMV)…


Any time you use a looks block that can potentially change the look of a sprite (see above for list of such), it is very expensive.

SPECIAL NOTE - THIS NEXT LINE IS VERY IMPORTANT - YES, I KNOW I'M WRITING IN CAPS …
Even if the looks block sets the sprite to look the same as it already is, or even if the sprite is hidden, Scratch still goes through all the (un)necessary calculations to make that change! -And it's a lot of work! (For example, if you're setting the ghost effect to 50 when it already is set to 50, or switching costume to the costume it already is set to.)


What I see very often is something along these lines:

forever
if (some-variable = somevalue) then
set ghost effect to 50
else
set ghost effect to 100

That means that every iteration of the loop it is applying a ghost effect - even if the variable it's checking has not changed.

It's somewhat unfortunate, I feel, that Scratch tends to make such style of scripting very easy, when it's so bad for performance.


A more efficient way of doing it is to at least check the setting before you reset it, where you can (e.g. if it's the size or direction there is a reporter you can use to compare against):

forever
if (some-variable = somevalue) then
if not (size=50) then
set size to 50 %
else
if not (size=100) then
set size to 100 %

For effects you don't have a reporter, so you'd have to make a (local) variable for the sprite so you can keep your own record of what the current setting is…


But ideally, you would only make the change to the look of the sprite at the same point that the variable gets changed. But if it's in a different sprite then you can't do that directly (which may well be why you put it into that forever/repeat loop to begin with…)
So, an even better way than using the extra checks shown in the forever loop above would be to send a broadcast at the point where the variable actually changes - and then make the appropriate change to the look of the sprite when the sprite receives that broadcast…

So something like this where the checked variable gets changed:

set some-variable to somevalue
broadcast “some-variable was changed”

Then receive it like this to make the change to the look:

when I receive “some-variable was changed”
if (some-variable = somevalue) then
set ghost effect to 50
else
set ghost effect to 100

In this case you have to remember to set the effect (or whatever it may be) to the desired value at the start (or send the broadcast at the start to get it set up correctly).


If you look through your projects and follow the above advice, you may well find it makes a significant difference to how well it performs…

Hope that's useful!

Okay, so I need to cut back on the graphic effects. I don't think a lot of what you said is in this project though, except for a couple elements that are changing color.

Thanks, I guess I just need to take out all the effects… Though that's the ing that's making it look decent.

CAA14 wrote:

a couple elements that are changing color.

As of the current Flash Player and shader de-optimization on the ST's part, I can't do anything with the color effect without suffering from severe lag. It was mentioned that the ST is experimenting with a new shader that will handle effect changes more smoothly. Until then, we're stuck/limited, basically

Zparx wrote:

CAA14 wrote:

a couple elements that are changing color.

As of the current Flash Player and shader de-optimization on the ST's part, I can't do anything with the color effect without suffering from severe lag. It was mentioned that the ST is experimenting with a new shader that will handle effect changes more smoothly. Until then, we're stuck/limited, basically

Oh…. That explains it then. Well, at least I know, thanks.

Not sure if it will help or not, but try doing my tutorial. It worked great for me, so hopefully it should help you out as well! http://scratch.mit.edu/discuss/topic/12829/

shadowspear1 wrote:

Not sure if it will help or not, but try doing my tutorial. It worked great for me, so hopefully it should help you out as well! http://scratch.mit.edu/discuss/topic/12829/

Thanks.