Is there a way to make a project not lag as much because I can't play it on full screen at all and on a smaller screen it's still lags.

What are your computer specifications?
-RAM
-processor
Are you using graphic effects? Those cause a lot of lag.

turkey3 wrote:

What are your computer specifications?
-RAM
-processor
Are you using graphic effects? Those cause a lot of lag.

I have 4GB of RAM

Intel(R) Pentium(R) CPU B980 @ 2.40GHz

Kyle2Death wrote:

turkey3 wrote:

What are your computer specifications?
-RAM
-processor
Are you using graphic effects? Those cause a lot of lag.

I have 4GB of RAM

Intel(R) Pentium(R) CPU B980 @ 2.40GHz

Thanks! Can you provide a link? Or is it unshared? And are you using graphic effects?

turkey3 wrote:

Kyle2Death wrote:

turkey3 wrote:

What are your computer specifications?
-RAM
-processor
Are you using graphic effects? Those cause a lot of lag.

I have 4GB of RAM

Intel(R) Pentium(R) CPU B980 @ 2.40GHz

Thanks! Can you provide a link? Or is it unshared? And are you using graphic effects?

No I am not.

Link? Do you mean the project? It's one of my Projects, http://scratch.mit.edu/projects/12392662/
However, when I play it in the 1.4 Offline Editer, It does not lag in full screen.

Kyle2Death wrote:

turkey3 wrote:

Kyle2Death wrote:

turkey3 wrote:

What are your computer specifications?
-RAM
-processor
Are you using graphic effects? Those cause a lot of lag.

I have 4GB of RAM

Intel(R) Pentium(R) CPU B980 @ 2.40GHz

Thanks! Can you provide a link? Or is it unshared? And are you using graphic effects?

No I am not.

Link? Do you mean the project? It's one of my Projects, http://scratch.mit.edu/projects/12392662/
However, when I play it in the 1.4 Offline Editer, It does not lag in full screen.

It lags on 8 gigabytes of RAM, too, and would probably on 50. The problem is the brightness effect you use in the buttons, because in version 11.8 of Adobe Flash, released on July 9, pixelender was removed, which is the code and part of Flash that makes all graphical effects run smoothly. They said it was for security reasons, and you can read more about it here. Remove all graphic effect blocks and find a workaround, and in couple of weeks when the lag is fixed by the Scratch Team, then implement them again. Also, you have many lengthy scripts that could be reduced with use of variables.

Well the thing is that the graphic effects are needed to solve some of the questions and if I do a workaround, it will triple the all ready over 1000 costumes, and the scripts will be even longer.
For the many lengthy scripts, I can't do much about, there for debug and for some of the questions and it wont work right if I put them in variables, and that will take weeks, having to rewrite most of the project.
My project, “Kyle2Death's Quiz” is 10,035KB, witch is a lot. I can't do much about that to, because the project is HUGE. However, I think I can compress the project, making it use less memory.
I guess I have to let the Scratch team fix it.

Thinks.

I think it is the very large number of IFs required to get to the answer. Why don't you build lists for each of the answer blocks. They would be indexed by stage. One list would be CORRECT? The other would be BROADCAST #.

scubajerry wrote:

I think it is the very large number of IFs required to get to the answer. Why don't you build lists for each of the answer blocks. They would be indexed by stage. One list would be CORRECT? The other would be BROADCAST #.

It can't work like that because some questions do diffint things.

Kyle2Death wrote:

scubajerry wrote:

I think it is the very large number of IFs required to get to the answer. Why don't you build lists for each of the answer blocks. They would be indexed by stage. One list would be CORRECT? The other would be BROADCAST #.

It can't work like that because some questions do diffint things.

You could make them the exceptions.

scubajerry wrote:

Kyle2Death wrote:

scubajerry wrote:

I think it is the very large number of IFs required to get to the answer. Why don't you build lists for each of the answer blocks. They would be indexed by stage. One list would be CORRECT? The other would be BROADCAST #.

It can't work like that because some questions do diffint things.

You could make them the exceptions.

That will break the game.

Kyle2Death wrote:

Is there a way to make a project not lag as much because I can't play it on full screen at all and on a smaller screen it's still lags.

Yes, as a number of others have noted here, you have a lot of forever loops where you are always setting the costume for a sprite, and sometimes some effects too.

The only way to reduce the lag in your project is to stop doing that and instead only change costume/effect as little as possible - when something does actually change.

Let me give you an example…
In your “Stage” sprite you have something like the following (missed out non-essential script):

when I receive [1 v]
stuff...
forever
  if <(Stage)=[1]> then
    go to x: (-175) y: (120)
    switch costume to [1 v]
  end
  if <(Stage)=[2]> then
    go to x: (-175) y: (120)
    switch costume to [2 v]
  end
  and lots more if checks like above...
end

This means when Stage=1, for example, it is continually and unnecessarily switching to costume 1 because it is always going around that “forever” loop, finding Stage=1, and setting the costume (to what it already is anyway!)


If you want to kill the lag, you really need to rewrite all of the scripts like above so they are more ‘event-based’. What I mean by that is that they only perform the costume change (and/or graphic effects for other cases) once, as soon as the condition becomes true (e.g. once Stage becomes 1, for example).

I'd suggest the following approach as probably the quickest way around it…
For the above case, where it does lots of checks for the value of variable “Stage”, instead of having it check in a forever loop, instead you should have a broadcast (e.g. “stage changed”) which is sent when the value of “Stage” gets changed/set - so from all those scripts in the “Question” sprite.
Now you can take all those “if Stage=something” checks you have (as shown above) out of the forever loop and just have them under a single “when I receive stage changed” hat block:

when I receive [stage changed v]
  if <(Stage)=[1]> then
    go to x: (-175) y: (120)
    switch costume to [1 v]
  end
  if <(Stage)=[2]> then
    go to x: (-175) y: (120)
    switch costume to [2 v]
  end
  and lots more if checks like above...

This means once variable Stage gets changed (in “Questions” sprite), the “stage changed” broadcast gets sent, and the script above only sets the costume once - and then it finishes.

Now, once you have the “stage changed” broadcasts in place wherever you change the value of variable “Stage”, there are lots of other sprites where you can immediately do the same kind of thing as above (just take all those “if Stage=something” checks out of the surrounding forever loops and put them under “when I receive stage changed”).


That will make a significant difference, for a start - but there are also other places where you should rethink the way you're changing the effects. For example, in your “Answer1/2/3/4” sprites you have a couple of scripts like this:

when I receive [1 v]
forever
  if <<touching [mouse pointer v]?> and <not <mouse down?>>> then
    set [color v] effect to (0)
    set [brightness v] effect to (20)
  end
  if <not<touching [mouse pointer v]?>> then
    set [color v] effect to (0)
    set [brightness v] effect to (0)
  end
  if <<touching [mouse pointer v]?> and <mouse down?>> then
    set [color v] effect to (20)
    set [brightness v] effect to (0)
  end
end
when this sprite clicked
wait until <not <mouse down?>>
if <touching [mouse pointer v]?> then
  do stuff for the click...

Again, the first script above is continually changing both colour effect and brightness! But those things only need to change once at each point the mouse pointer touches or stops touching the sprite, and once each time the mouse button changes.

How about something like this instead:

when I receive [stage changed v]
set [color v] effect to (0)
forever // this loop is only doing move in/out changes if not clicking on sprite - clicking done in script below
  set [brightness v] effect to (0)
  wait until <touching [mouse pointer v]?>
  wait until <not <mouse down?>> // don't want to change effect if in middle of clicking on sprite
  if <touching [mouse pointer v]?> then // check if still touching after mouse button released
    set [brightness v] effect to (20)
  end
  wait until <not <touching [mouse pointer v]?>>
when this sprite clicked
repeat until <not <mouse down?>> // this replaces the "wait until" you had before, and does in/out changes when clicking
  set [color v] effect to (20)
  set [brightness v] effect to (0)
  wait until <<not <touching [mouse pointer v]?>> or <not <mouse down?>>>
  set [color v] effect to (0)
end
if <not <touching [mouse pointer v]?>> then
  set [color v] effect to (0) // wasn't over sprite when mouse button released
  set [brightness v] effect to (0)
else
  do stuff for the click...
end

Hope I've got that right! -But if not, hopefully you'll get the idea.

I'm afraid you do have a lot of work here, because you have such script constructions all over your sprites (i.e. continually switching costume/effect within loops). But it's really the only way you're going to kill the lag…

Wow, that ended up a longer than I expected, but I hope it helps!

@DadofMrLog: I was waiting for the lag master to vote (your nickname by me)

DadOfMrLog wrote:

Kyle2Death wrote:

Is there a way to make a project not lag as much because I can't play it on full screen at all and on a smaller screen it's still lags.

Yes, as a number of others have noted here, you have a lot of forever loops where you are always setting the costume for a sprite, and sometimes some effects too.

The only way to reduce the lag in your project is to stop doing that and instead only change costume/effect as little as possible - when something does actually change.

Let me give you an example…
In your “Stage” sprite you have something like the following (missed out non-essential script):

when I receive [1 v]
stuff...
forever
  if <(Stage)=[1]> then
    go to x: (-175) y: (120)
    switch costume to [1 v]
  end
  if <(Stage)=[2]> then
    go to x: (-175) y: (120)
    switch costume to [2 v]
  end
  and lots more if checks like above...
end

This means when Stage=1, for example, it is continually and unnecessarily switching to costume 1 because it is always going around that “forever” loop, finding Stage=1, and setting the costume (to what it already is anyway!)


If you want to kill the lag, you really need to rewrite all of the scripts like above so they are more ‘event-based’. What I mean by that is that they only perform the costume change (and/or graphic effects for other cases) once, as soon as the condition becomes true (e.g. once Stage becomes 1, for example).

I'd suggest the following approach as probably the quickest way around it…
For the above case, where it does lots of checks for the value of variable “Stage”, instead of having it check in a forever loop, instead you should have a broadcast (e.g. “stage changed”) which is sent when the value of “Stage” gets changed/set - so from all those scripts in the “Question” sprite.
Now you can take all those “if Stage=something” checks you have (as shown above) out of the forever loop and just have them under a single “when I receive stage changed” hat block:

when I receive [stage changed v]
  if <(Stage)=[1]> then
    go to x: (-175) y: (120)
    switch costume to [1 v]
  end
  if <(Stage)=[2]> then
    go to x: (-175) y: (120)
    switch costume to [2 v]
  end
  and lots more if checks like above...

This means once variable Stage gets changed (in “Questions” sprite), the “stage changed” broadcast gets sent, and the script above only sets the costume once - and then it finishes.

Now, once you have the “stage changed” broadcasts in place wherever you change the value of variable “Stage”, there are lots of other sprites where you can immediately do the same kind of thing as above (just take all those “if Stage=something” checks out of the surrounding forever loops and put them under “when I receive stage changed”).


That will make a significant difference, for a start - but there are also other places where you should rethink the way you're changing the effects. For example, in your “Answer1/2/3/4” sprites you have a couple of scripts like this:

when I receive [1 v]
forever
  if <<touching [mouse pointer v]?> and <not <mouse down?>>> then
    set [color v] effect to (0)
    set [brightness v] effect to (20)
  end
  if <not<touching [mouse pointer v]?>> then
    set [color v] effect to (0)
    set [brightness v] effect to (0)
  end
  if <<touching [mouse pointer v]?> and <mouse down?>> then
    set [color v] effect to (20)
    set [brightness v] effect to (0)
  end
end
when this sprite clicked
wait until <not <mouse down?>>
if <touching [mouse pointer v]?> then
  do stuff for the click...

Again, the first script above is continually changing both colour effect and brightness! But those things only need to change once at each point the mouse pointer touches or stops touching the sprite, and once each time the mouse button changes.

How about something like this instead:

when I receive [stage changed v]
set [color v] effect to (0)
forever // this loop is only doing move in/out changes if not clicking on sprite - clicking done in script below
  set [brightness v] effect to (0)
  wait until <touching [mouse pointer v]?>
  wait until <not <mouse down?>> // don't want to change effect if in middle of clicking on sprite
  if <touching [mouse pointer v]?> then // check if still touching after mouse button released
    set [brightness v] effect to (20)
  end
  wait until <not <touching [mouse pointer v]?>>
when this sprite clicked
repeat until <not <mouse down?>> // this replaces the "wait until" you had before, and does in/out changes when clicking
  set [color v] effect to (20)
  set [brightness v] effect to (0)
  wait until <<not <touching [mouse pointer v]?>> or <not <mouse down?>>>
  set [color v] effect to (0)
end
if <not <touching [mouse pointer v]?>> then
  set [color v] effect to (0) // wasn't over sprite when mouse button released
  set [brightness v] effect to (0)
else
  do stuff for the click...
end

Hope I've got that right! -But if not, hopefully you'll get the idea.

I'm afraid you do have a lot of work here, because you have such script constructions all over your sprites (i.e. continually switching costume/effect within loops). But it's really the only way you're going to kill the lag…

Wow, that ended up a longer than I expected, but I hope it helps!

Well, that's not really causing the lag, the lag is the effects, because I use 1.4 for this project, and it works fine on it.
And the effects are:
When your mouse is not touching the sprite, it will do nonthing.
If it is but NOT mousedown, then it will be brighter.
When the mouse IS down, and the mouse is on the sprite, then it will chage color.

Actually, I believe it is a problem with the Flash player. ST is working on a fix.

Yes, @Kyle2Death, you're right that it is the effects (mostly) causing the lag - that's what I said!
But the important point is that it's your scripts that are telling it to apply those effects continually, when you (most of the time) don't need to…


@Eintity: yes, if you have Flash 11.8, Kyle2Death's quiz project will completely grind to halt because of those effects being continually applied. However, even with 11.7 it will struggle on slower machines, because there are also lots of other things happening continually in lots of sprites at the same time (mainly costume switches) - I find it pretty much too sluggish on my old Mac Mini, even without going full-screen. (No, I haven't upgraded to 11.8 because I know that will mean I have to force-quit the browser every half-hour or so if I start trying out projects, with so many having scripted use of effects in this way.)
Expanding a project so it has more and more sprites with forever loops that continually change costume/effect/size/rotation… well, eventually any computer is bound to reach its limit. You can get away with it for smaller projects, and only a few sprites (unless flash 11.8!), but if you want to make really great projects, the best option is really not to start down that route at all…


Back to @Kyle2Death: The reason it works with 1.4 is because that scheduled its loops in a different (much slower) way - but 2.0 tries to run through loops much more quickly, in an attempt to make projects with calculations in loops run faster (it's kinda slightly more like turbo mode in certain ways).
Unfortunately, it backfires for cases like this because it ends up having to perform complex calculations way more often if you have loads of sprites; after all, that's what you've told it to do! - effectively: "repeat these costume/effects changes in all these sprites as often as you can". (Effects are the worst culprits, but even switching costume, or rotating, or resizing - anything that changes the look of a sprite - should be done as frugally as possible).

“When your mouse is not touching the sprite, it will do nonthing.”

Unfortunately, that's not quite the way the computer sees it. It's more like this:
“All the time your mouse is not touching the sprite, keep recalculating the bitmap for the sprite's current costume (with no effects applied).” - it's because of the “set color/brightness effect to 0” blocks that it does those calculations.
(It may not make much sense that it should do it like that, but unfortunately that is what it does.)
Similarly when touching, but with mouse button up, it's continually doing the same calculation but also having to continually apply brightness on top of that.

Note also that if you switch costume all the time in a loop - even for a hidden sprite, and/or even if it's already on that costume(!) - it has to do the same kind of recalculating of the sprite's bitmap, ready to be shown on the screen at the next screen-refresh. Also, the same if you set some graphic effect or change its size, or change its rotation direction - and I emphasize again: even if the sprite is hidden, and/or even if the effect/size/direction setting is already at that value(!) Again, may not make much sense that it should work like that, but…

As I noted above, you can get away with doing this if you're not using that many sprites. But as your projects grows, and you want it to do more and more, you will eventually get to the point where you have to start taking such excessive computation seriously!


Bottom line (for everyone, really!): if you want such projects to work well under Scratch 2.0 for as many users as possible, and especially if you plan to put a lot into it, then you have no choice but to change your scripting methodology - away from forever loops with embedded continual changes of sprite looks, and towards applying such changes as and when specific ‘events’ happen.

Final advice @Kyle2Death: I've given you specific examples of how you can change certain aspects of your project without having to totally rescript everything. Now you should schedule a good chunk of time to spend going through your project making such changes, starting with the effects, and moving on to costume switches. I promise your lag will practically vanish (even full-screen) - and remember to keep scripting it like that from now on!

DadOfMrLog wrote:

Yes, @Kyle2Death, you're right that it is the effects (mostly) causing the lag - that's what I said!
But the important point is that it's your scripts that are telling it to apply those effects continually, when you (most of the time) don't need to…


@Eintity: yes, if you have Flash 11.8, Kyle2Death's quiz project will completely grind to halt because of those effects being continually applied. However, even with 11.7 it will struggle on slower machines, because there are also lots of other things happening continually in lots of sprites at the same time (mainly costume switches) - I find it pretty much too sluggish on my old Mac Mini, even without going full-screen. (No, I haven't upgraded to 11.8 because I know that will mean I have to force-quit the browser every half-hour or so if I start trying out projects, with so many having scripted use of effects in this way.)
Expanding a project so it has more and more sprites with forever loops that continually change costume/effect/size/rotation… well, eventually any computer is bound to reach its limit. You can get away with it for smaller projects, and only a few sprites (unless flash 11.8!), but if you want to make really great projects, the best option is really not to start down that route at all…


Back to @Kyle2Death: The reason it works with 1.4 is because that scheduled its loops in a different (much slower) way - but 2.0 tries to run through loops much more quickly, in an attempt to make projects with calculations in loops run faster (it's kinda slightly more like turbo mode in certain ways).
Unfortunately, it backfires for cases like this because it ends up having to perform complex calculations way more often if you have loads of sprites; after all, that's what you've told it to do! - effectively: "repeat these costume/effects changes in all these sprites as often as you can". (Effects are the worst culprits, but even switching costume, or rotating, or resizing - anything that changes the look of a sprite - should be done as frugally as possible).

“When your mouse is not touching the sprite, it will do nonthing.”

Unfortunately, that's not quite the way the computer sees it. It's more like this:
“All the time your mouse is not touching the sprite, keep recalculating the bitmap for the sprite's current costume (with no effects applied).” - it's because of the “set color/brightness effect to 0” blocks that it does those calculations.
(It may not make much sense that it should do it like that, but unfortunately that is what it does.)
Similarly when touching, but with mouse button up, it's continually doing the same calculation but also having to continually apply brightness on top of that.

Note also that if you switch costume all the time in a loop - even for a hidden sprite, and/or even if it's already on that costume(!) - it has to do the same kind of recalculating of the sprite's bitmap, ready to be shown on the screen at the next screen-refresh. Also, the same if you set some graphic effect or change its size, or change its rotation direction - and I emphasize again: even if the sprite is hidden, and/or even if the effect/size/direction setting is already at that value(!) Again, may not make much sense that it should work like that, but…

As I noted above, you can get away with doing this if you're not using that many sprites. But as your projects grows, and you want it to do more and more, you will eventually get to the point where you have to start taking such excessive computation seriously!


Bottom line (for everyone, really!): if you want such projects to work well under Scratch 2.0 for as many users as possible, and especially if you plan to put a lot into it, then you have no choice but to change your scripting methodology - away from forever loops with embedded continual changes of sprite looks, and towards applying such changes as and when specific ‘events’ happen.

Final advice @Kyle2Death: I've given you specific examples of how you can change certain aspects of your project without having to totally rescript everything. Now you should schedule a good chunk of time to spend going through your project making such changes, starting with the effects, and moving on to costume switches. I promise your lag will practically vanish (even full-screen) - and remember to keep scripting it like that from now on!

Wow. This became a simple question to a complex problem.
I'm not sure how long this will take or if I will ever do it.
I will let the Scratch team fix the thing first, then I will work on it.
The reason the scripts is like that because I started this back in 1.4, and I was new back then.

Kyle2Death wrote:

Wow. This became a simple question to a complex problem.
I'm not sure how long this will take or if I will ever do it.

It's a bit tedious to go through and do it all, so it will take an hour or so, but it's not really that hard to do (at least most of it, which should make enough of a difference).

I will let the Scratch team fix the thing first, then I will work on it.

Are you using Flash 11.8? Do you find running your project (not even full-screen) makes your browser lock up until you somehow stop it running?
Since you talked about the problem being full-screen, my guess would be that you don't have the more serious Flash 11.8 problem -you'd not be able to run it all if you did. If that's the case, then the fix for that problem won't make any difference for you, unfortunately.

The reason the scripts is like that because I started this back in 1.4, and I was new back then.

It's probably the most common way to script these things - I've written about it a number of times on the forums here. I think it's a pity that Scratch makes such a technique so easy - and then you can end up getting so badly hit by it as your projects start to really expand

Anyway, I finally got around to writing a project that demonstrates it!
Gives me an example to link to in future: http://scratch.mit.edu/projects/12438833/
Hope that helps!

DadOfMrLog wrote:

Kyle2Death wrote:

Wow. This became a simple question to a complex problem.
I'm not sure how long this will take or if I will ever do it.

It's a bit tedious to go through and do it all, so it will take an hour or so, but it's not really that hard to do (at least most of it, which should make enough of a difference).

I will let the Scratch team fix the thing first, then I will work on it.

Are you using Flash 11.8? Do you find running your project (not even full-screen) makes your browser lock up until you somehow stop it running?
Since you talked about the problem being full-screen, my guess would be that you don't have the more serious Flash 11.8 problem -you'd not be able to run it all if you did. If that's the case, then the fix for that problem won't make any difference for you, unfortunately.

The reason the scripts is like that because I started this back in 1.4, and I was new back then.

It's probably the most common way to script these things - I've written about it a number of times on the forums here. I think it's a pity that Scratch makes such a technique so easy - and then you can end up getting so badly hit by it as your projects start to really expand

Anyway, I finally got around to writing a project that demonstrates it!
Gives me an example to link to in future: http://scratch.mit.edu/projects/12438833/
Hope that helps!

Well I used it, did not work so well…

You just did for mouse over, my sprites also change if the mouse if HELD DOWN but not yet let go, because of that, it did not work.

Kyle2Death wrote:

You just did for mouse over, my sprites also change if the mouse if HELD DOWN but not yet let go, because of that, it did not work.

Do you mean in the example project I just made? -If so, yes, sure, that only has an example for mouse-over.
But that project wasn't directed specifically at your project (I've made… several… posts… in the forums for other Scratchers, as well as some… project… comments -it's probably the most common lag issue Scratchers run into).

The demo project was more a general demonstration of the issue, along with a conceptual solution (waiting for something, rather than looping) that would hopefully be taken and used in a more specific way as needed. -And something I could link in future when posting again on the same topic…

But for your case, I did outline a solution in the scratchblocks of an earlier post in this topic.
The mouseover was done in one script (very similar to the example project), but the click-and-hold case is dealt with in the second script (“when this sprite clicked”).

Actually, if you look at the scripts for the button at top-right of that demo project, you'll see I did implement very much the kind of thing you're after (if you hold down the mouse button and drag on/off the sprite, it also changes).

I think that should be pretty much the same as what you're after, so go take a look at that, too!