I do believe

when [loudness/video/timer v] > (10)

should be replaced with

when <> is true::events hat

to eliminate the processor-consuming

when green flag clicked
forever
if <> then
...
end
end

Thank you for your time.

They both would have to check the condition every frame refresh, why would one be more efficient than the other? Just wondering

jokebookservice1 wrote:

They both would have to check the condition every frame refresh, why would one be more efficient than the other? Just wondering

I read on the Scratch Wiki that “forever if” (cut) generated a few ms less lag than the workaround, so wouldn't condensing all of that into one block generate even less lag? My logic is probably flawed.

Support.

LemonComputer wrote:

Support.

Why? Please back up your opinions with reasoning; its why you support that really matters, not if you do

Sigton

I think it should be

when <> ::events ::hat

not

when <> is true ::events hat

but still, support.

HoofEMP wrote:

jokebookservice1 wrote:

They both would have to check the condition every frame refresh, why would one be more efficient than the other? Just wondering

I read on the Scratch Wiki that “forever if” (cut) generated a few ms less lag than the workaround, so wouldn't condensing all of that into one block generate even less lag? My logic is probably flawed.

Just ran a test between

when [timer v] > (0.1)

and

forever
if <(timer) > [0.1]> then

end
end

Turns out the second is faster, by about 60 milliseconds.

Also, I've said this like 103,294 times, something being faster by “a few milliseconds” affects the project you're making just as much as me going to the beach many times affects my chance of being shot by a dog with a gun in its mouth. Sure, it's something, but that doesn't mean it's worth considering.

stop [all v] ::stack

60 ms is 2 frames – quite a difference.

Anyway, this shows it is more accurate. Try the test with a “wait until” bock and I think (again, just a prediction) that it will be as inaccurate as a hat block.

jokebookservice1 wrote:

60 ms is 2 frames – quite a difference.

Anyway, this shows it is more accurate. Try the test with a “wait until” bock and I think (again, just a prediction) that it will be as inaccurate as a hat block.

How I ran the test:
Speed calculator:

set [a v] to [0]
reset timer
wait until <(a) = [1]>
set [time v] to (((timer) - (0.1)) * (1000))

Test 1:

when [timer v] > (0.1)
set [a v] to [1]

Result: About 33.44 ms

Test 2:

forever
if <(timer) > [0.1]> then
set [a v] to [1]
end
end

Result: About 1.38 ms

Test 3:

forever
wait until <(timer) > [0.1]>
set [a v] to [1]
end

Result: About 1.28 ms

stop [all v] ::stack

Alberknyis wrote:

jokebookservice1 wrote:

60 ms is 2 frames – quite a difference.

Anyway, this shows it is more accurate. Try the test with a “wait until” bock and I think (again, just a prediction) that it will be as inaccurate as a hat block.

How I ran the test:
Speed calculator:

set [a v] to [0]
reset timer
wait until <(a) = [1]>
set [time v] to (((timer) - (0.1)) * (1000))

Test 1:

when [timer v] > (0.1)
set [a v] to [1]

Result: About 33.44 ms

Test 2:

forever
if <(timer) > [0.1]> then
set [a v] to [1]
end
end

Result: About 1.38 ms

Test 3:

forever
wait until <(timer) > [0.1]>
set [a v] to [1]
end

Result: About 1.28 ms

(redacted)

HoofEMP wrote:

Alberknyis wrote:

Post 10

(removed by moderator - please keep it polite) , that's a huge difference. I no longer support my own idea.

Hey hey hey, something tells me we should *blame* the Scratch Team and not the suggestion after all, they all should run at about the same speed (unless I'm misinformed)

stop [all v] ::stack

@Alberknyis:

Unfortunately, the timings you get are not comparable in any sensible way, due to the way the Scratch execution engine schedules loop and hat block processing.

In the case of the “when timer” hat block (and any other such hat block), these only get checked first thing after each screen refresh (unless in turbo mode), which is every 1/30th second – hence the times of ~33ms.

In the case of loops and wait until, if there is nothing happening that (potentially) changes something on-screen, then it all gets run as if in turbo mode – hence the times of ~1ms.

However, if you placed a “go to x: 0 y: 0” block in the forever loop (or any other loop running concurrently with it) then Scratch will throttle the loop speed to 30x per second (unless you run in turbo), and you'll be back to times of ~33ms…

Basically, you're not really doing anything more than timing screen refresh at the moment with your “when timer” block.

TheLogFather wrote:

In the case of the “when timer” hat block (and any other such hat block), these only get checked first thing after each screen refresh (unless in turbo mode), which is every 1/30th second – hence the times of ~33ms.

… Dayum. I was wondering what was going on with the *coincidental* 33 ms delay. So in most (a lot of) circumstances they'd go at pretty much the same speed?

stop [all v] ::stack

Alberknyis wrote:

… Dayum. I was wondering what was going on with the *coincidental* 33 ms delay. So in most (a lot of) circumstances they'd go at pretty much the same speed?

Yes, quite.

However, the scripts for hat blocks get appended to the list of active scripts, and then it goes through the currently active scripts and executes, up until the next yield (end of loop, or a wait, etc.), each one.

That means the hat block will start its execution after all of the scripts that were already active have reached their yield points.

In that sense I guess it means these previously active scripts will have had a chance to ‘get in there’ with a relevant test before the hat block script starts up… (If there happens to be an intensive script that runs for a while during this refresh, then the hat block could be delayed for some time. So, a script that is scheduled to run before such an intensive script could ‘catch’ the condition earlier than the hat block script.)

However, it all rather depends on knowing exactly how the various scripts within a sprite, and across sprites, get ordered for execution, and ‘engineering’ the script execution order to take advantage of the timing.

HoofEMP wrote:

I do believe

when [loudness/video/timer v] > (10)

should be replaced with

when <> is true::events hat

to eliminate the processor-consuming

when green flag clicked
forever
if <> then
...
end
end

Thank you for your time.

Support! This could make code for projects neater too!