I think that the scratch team should raise the clone limit to 500, or 450 or something. It can help with some projects so that people won't have to duplicate sprites. They put the clone limit there to prevent lag, but duplicating sprites would clog up assets, which would lag it a lot more than cloning. And cloning really only lags when making the clone, while a lot more sprites not only lags a lot more than clones, but also makes the code hard to understand for newbies. Clone limits also limit what scratchers can do, and this is a perfect example. I think that a larger clone limit would make programming in scratch a lot easier, and a lot better for others to see scratch projects, and also make sure scratchers don't get deterred from other's project because of lag.

You are aware that it's 300(301) clones TOTAL, right? Multiple sprites won't work. So if I have, let's say, 299 clones on one sprite, and I start cloning another sprite, I can only clone that other sprite 1 or 2 more times before it stops. Just throwing that out there.

And about the lag- it's not just when making them. Try cloning exponentially(As in, clones make clones) and see how much it lags AFTER all the clones have been made.

The limit is high enough as it is- it can brutally lag up the computers at my school.

Listwizard wrote:

You are aware that it's 300(301) clones TOTAL, right? Multiple sprites won't work. So if I have, let's say, 299 clones on one sprite, and I start cloning another sprite, I can only clone that other sprite 1 or 2 more times before it stops. Just throwing that out there.

And about the lag- it's not just when making them. Try cloning exponentially(As in, clones make clones) and see how much it lags AFTER all the clones have been made.

The limit is high enough as it is- it can brutally lag up the computers at my school.

Yes, I am aware that it is 300 clones total. The project of of mine up there is meant to show that it doesn't lag as much. The purpose of this thread is to see how much clones lag less then duplicating sprites, which clog the project up more and make it less user friendly. Maybe my project wasn't the best example. Sorry about that…

This is why Scratch needs hardware acceleration. Your poor CPU has to do all the work, information, calculation, and visuals/graphics which the GPU could help with.

@TC01017:

Was looking at your project and I suspect you've not quite understood how the Scratch looping system works…

As expected, each loop of a repeat where a clone gets created also allows a screen refresh, so there's the normal Scratch loop timing of 1/30th second beteween each one.
However, if you do the clone creation in multiple sprites, it goes through the sprites and does an iteration of each sprite's repeat loop within the same ‘refresh time’ (1/30th second) - i.e. it would then be going through a single repeat of all sprites within 1/30th second, rather than just the one repeat of the one sprite in 1/30th second, so it appears to be creating them N times faster (where N is the number of sprites you have creating clones).

Working with lots of clones doesn't cause any more lag than lots of sprites (might even be faster, but not tested that…) It's just the way that you've told it to create the clones from the same sprite within a refresh-enabled loop that's making it create them more slowly. Try putting your clone creation into a non-refresh custom block and watch it fly…

“Working with lots of clones doesn't cause any more lag than lots of sprites (might even be faster, but not tested that…)”
That is the whole point! I am saying that cloning would cause less lag than making a whole lot of sprites.

dusty22 wrote:

This is why Scratch needs hardware acceleration. Your poor CPU has to do all the work, information, calculation, and visuals/graphics which the GPU could help with.

Yea, I think it needs that too. In fact, that could help with the lag from clones, which in turn could let the scratch team raise the clone limit!

Oh, huh? Really odd - for some reason when I read your post I understood it as you saying that clones caused ‘lag’ whereas sprites didn't.
Re-reading it, I'm not sure how I came to that conclusion.

Actually, I'm still not clear what you're saying about the ‘lag’…
Under what situation do you see lag? Is it when you try to, say, clone a dozen or so clones from a dozen sprites at the same time?
And you're saying that cloning lots from a single sprite is ok?

DadOfMrLog wrote:

Oh, huh? Really odd - for some reason when I read your post I understood it as you saying that clones caused ‘lag’ whereas sprites didn't.
Re-reading it, I'm not sure how I came to that conclusion.

Actually, I'm still not clear what you're saying about the ‘lag’…
Under what situation do you see lag? Is it when you try to, say, clone a dozen or so clones from a dozen sprites at the same time?
And you're saying that cloning lots from a single sprite is ok?

Yes, in comparison to making 300 clones and then duplicating X (without cloning scripts) sprites from right click menu would lag a lot more than just making 300+X clones.

BTW, concering GPU…
Scratch is working through Flash, so it means to make use of the GPU from Scratch requires that Flash has access to it in the way that Scratch needs.

I don't know much about the details of how Flash uses GPU, but I suspect the main (only?) thing it does is provide playback decoders for specific types of video codecs (H.264 and the like) and maybe for rendering 3D graphics - and Scratch has nothing to ‘connect’ to any kind of standard 3D framework (e.g. OpenGL, DirectX), so it's not gonna use any of that.

What should happen first for Scratch, before GPU, would be to actually make use of multiple cores on the CPU - i.e. make use of some of the (limited?) multi-threading capabilities of Flash. That could suddenly pump up performance by a factor of 3 or 4, typically (on most CPUs these days) for certain things.

Now, having said that, I really suspect making Scratch multi-threaded would introduce a whole load of pain for a whole load of projects already uploaded - I bet the vast majority of Scratch project creators have not even considered the possible issues that would arise if some of their scripts started getting run at the same time as each other, effectively having different parts of different scripts run ‘interleaved’ with each other…
Imagine a script that changes a variable just as another script elsewhere is in the middle of performing a calculation based on the same variable.
And it's not surprising they haven't considered such things, because Scratch is aimed at (fairly young) kids, so they shouldn't have to (yet!)

Unfortunately, I'm not hopeful that there's a way to make Scratch multi-threaded that would really be ‘safe’.
But then it's possible the ‘geniusness’ on the Scratch Team knows no bounds, and they may be able to sneak at least some degree of multi-threading into certain parts in a way that makes a significant difference…

DadOfMrLog wrote:

BTW, concering GPU…
Scratch is working through Flash, so it means to make use of the GPU from Scratch requires that Flash has access to it in the way that Scratch needs.

I don't know much about the details of how Flash uses GPU, but I suspect the main (only?) thing it does is provide playback decoders for specific types of video codecs (H.264 and the like) and maybe for rendering 3D graphics - and Scratch has nothing to ‘connect’ to any kind of standard 3D framework (e.g. OpenGL, DirectX), so it's not gonna use any of that.

What should happen first for Scratch, before GPU, would be to actually make use of multiple cores on the CPU - i.e. make use of some of the (limited?) multi-threading capabilities of Flash. That could suddenly pump up performance by a factor of 3 or 4, typically (on most CPUs these days) for certain things.

Now, having said that, I really suspect making Scratch multi-threaded would introduce a whole load of pain for a whole load of projects already uploaded - I bet the vast majority of Scratch project creators have not even considered the possible issues that would arise if some of their scripts started getting run at the same time as each other, effectively having different parts of different scripts run ‘interleaved’ with each other…
Imagine a script that changes a variable just as another script elsewhere is in the middle of performing a calculation based on the same variable.
And it's not surprising they haven't considered such things, because Scratch is aimed at (fairly young) kids, so they shouldn't have to (yet!)

Unfortunately, I'm not hopeful that there's a way to make Scratch multi-threaded that would really be ‘safe’.
But then it's possible the ‘geniusness’ on the Scratch Team knows no bounds, and they may be able to sneak at least some degree of multi-threading into certain parts in a way that makes a significant difference…

Hmm… I never thought of it like that! Why not code it in half directX- half flash? Or Html5(if it allows it)?

Bump

TC01017 wrote:

I think that the scratch team should raise the clone limit to 500, or 450 or something. It can help with some projects so that people won't have to duplicate sprites. They put the clone limit there to prevent lag, but duplicating sprites would clog up assets, which would lag it a lot more than cloning. And cloning really only lags when making the clone, while a lot more sprites not only lags a lot more than clones, but also makes the code hard to understand for newbies. Clone limits also limit what scratchers can do, and this is a perfect example. I think that a larger clone limit would make programming in scratch a lot easier, and a lot better for others to see scratch projects, and also make sure scratchers don't get deterred from other's project because of lag.

You would be surprised. Back when I joined (1.3), you couldn't even clone sprites. 500 is a lot of clones, and I am sure the Scratch Team is trying to raise them.

It would be nice to get a warning when the limit was reached.

The work around isn't too nice, but it's more realistic. You keep every “clone”'s position and stuff in lists. One sprite goes through the lists, drawing all the “clones” with stamping. This will lag quickly, but allows you for “infinite” clones, and it's less laggy than clones, until you have 400-500, then it's nasty…

I don't think a higher clone limit would be a benefit. In this project, I have only 154 clones on the screen and it is already hard for the CPU to execute the code for each clone in time, which is the reason why I didn't go to a more fine-grained resolution. More clones only make sense if they are just there for display, not to be moved or executing code. But in this case, stamping performance should be improved (see SirScripts experiments on clones vs. stamping.

Please don't bump up old threads unless it's really necessary. The clone limit we've added is a practical one to prevent projects from becoming unplayable. Otherwise, you could accidentally get sprites making infinite copies of themselves and such.