New block similar to warp

I am suggesting a block which is a
[scratchblocks]
pause all except for{
}until that is done :: control
[/scratchblocks]
(or something like that)
so it's just a warp block but does not run the part of the script enclosed faster.

I think this request is incoherent. WARP doesn't make your thread run faster by overclocking your CPU! All it does is prevent the running of other threads, and so that gives the freed-up time to this thread.

So the warp block basically does what you want!
PS:I once had my browser crash because I had a forever loop in a warp :expressionless:

no it does not at all. see the "help" for warp, or try the script Screen Shot 2020-12-14 at 10.43.42 AM
then put a warp block on all of the script, and it will seem like it is not doing anything since it will be so fast.

i think at the end of a loop, the thread pauses for a while so other threads can work and so forever loops don't freeze Snap!. the warp block prevents this from happening. which is why putting a forever loop in a warp will crash Snap!.

um I think you replied to the wrong person

no i did not

i was originally going to write about how putting a warp block over the entire script would be the same as putting the warp block in the for loop, because the warp block only affects loops. but instead i explained why warp blocks only affected loops

Workaround:
untitled script pic (9)
Then put a
untitled script pic (10)
at the beginning of the main loop in every sprite, like this:
untitled script pic (11)

yeah, but then when the scripts are paused, it finishes the script, then it waits.

I know but if the script in the forever loop only runs for one frame then it shouldn't make a difference

Gack, you guys are making this way complicated. If you want to see the sides drawn one at a time, instead of
super set pen script pic
just do
super set pen script pic
But yeah, I guess if you want to prevent some other script from eating a lot of time without ever yielding, you could write something like @donotforgetmycode_sn's code, although I think it makes the assumption that a script just has one "main loop"; if you're in a situation like this, you know which other script is slowing you down, and you can just manually stop that one.

EDIT: Right, that WARP won't really do anything in this simple example of drawing a square, but if there's an inner loop inside it, warping the inner loop but not the outer one will do the trick. I just wanted to use the example from the help screen.

There is a huge difference between those scripts.
Let, for clarity, repeat(60). Then 1st script takes a few ms while the second ~1s.
And this is a main source of the perceived "slowness".
You probably know that Scratch has a much different strategy now.
Only the loops that make the screen "dirty" are yielding to screen refresh.

untitled script pic (7) This script takes 10s in Snap! while in Scratch 0.3s (even with 30FPS of Scratch).

Probably the best experience for an average user will be with "smooth turbo" with refresh timeout set to 15 - 30 instead of 500ms.

Yes, of course; the point of the second one is that I interpret the original post in this thread as asking for the display to update for each line drawn. So "slowness" is what's desired.

P.S. No, I didn't know about Scratch avoiding redisplay if nothing is dirty. But that has to mean more than just what's on the stage; for example the thumbnail sprite pictures in the sprite corral change if a sprite rotates.

no it does not.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.