Scratch's way of delaying is a bit confusing for me, so I apologize if I missed something obvious.

Is there any way I could replicate a delay like that in this project (you have to choose yes when prompted after clicking the flag)? I need a delay that can be precise to the millisecond, and not just being delayed by a certain number of Scratch frames.

I was only able to delay something by a certain number of Scratch frames relative to time (although it wasn't very accurate; it was basically in 30ths of a second, not thousandths). I put all my code inside a custom block with “run without screen refresh”. Here's my code:

define delay
set [end time v] to (((days since 2000) * (86400000)) + (delay \(ms\)))
repeat until <(end time) < ((days since 2000) * (86400000))>
set volume to (100) % // this delays it by one frame, yet other methods lag the project
end

“delay (ms)” is the number of milliseconds that this delay block should halt the script

I don't think that it's possible to get any more accurate than that.
Could be wrong, though.
How are you measuring the delay?

wendiner wrote:

I don't think that it's possible to get any more accurate than that.
Could be wrong, though.
How are you measuring the delay?

I'm measuring by milliseconds - and I'm pretty sure it's possible, as indicated by this project. I'm not sure how to replicate it though.

This is the custom block used in the project:


The change effect and set effect blocks wait until the next tick (which I'm guessing is a millisecond), allowing it to be super precise.
this is just my understanding

Hi -Qlec-,

I looked at the Fast Mergesort project you linked. In the Visual sprite, -Rex- defines Delay similarly to what you showed in your topic post. If you right click on the define block and pick edit, you'll see they do have “Run without screen refresh” checked (which doesn't introduce lag problems if the loop is of very limited duration and contains no waits).

That ensures blocks that normally request the scratch virtual machine to pause to the next 1/30 second frame will spin as fast as they can. (Up to a certain time limit–then they lag really badly.)

A couple things though.

1. Human reaction time is much slower than what you're talking about. 150-300 ms is a good guide (you'll see slightly different ranges from different studies, but they seem pretty close).

2. The system clock in your computer (which scratch uses) only has a certain amount of accuracy. This depends on choices made by the operating system, based on hardware, and on choices made by software like your browser. E.g., I might have a system clock with 1 ms accuracy on my desktop computer, but if I move to my laptop I might only have 8 ms accuracy.

See this topic https://scratch.mit.edu/discuss/topic/620222 about timing (and the last post for details about the system clock).

– RT_Borg

Thingied wrote:

This is the custom block used in the project:


The change effect and set effect blocks wait until the next tick (which I'm guessing is a millisecond), allowing it to be super precise.
this is just my understanding

I don't think it delays it by a millisecond - this is an action that causes it to skip over a frame (I tried removing all the code from the delay block and added only a set volume block; it paused for a frame every time). Yes, I do have run without screen refresh enabled.

RT_Borg wrote:

1. Human reaction time is much slower than what you're talking about. 150-300 ms is a good guide (you'll see slightly different ranges from different studies, but they seem pretty close).

I'm not trying to make a game where a thing pops up every 2 ms and they have to click it before the next one shows up - I'm sorry if I misunderstood.

RT_Borg wrote:

2. The system clock in your computer (which scratch uses) only has a certain amount of accuracy. This depends on choices made by the operating system, based on hardware, and on choices made by software like your browser. E.g., I might have a system clock with 1 ms accuracy on my desktop computer, but if I move to my laptop I might only have 8 ms accuracy.

This is a valid point, but if you see @-Rex-'s project it manages to delay it even in such precise timings - change the slider a bit while sorting and you'll see.

-Qlec- wrote:

I don't think it delays it by a millisecond

It's not exactly a millisecond, but it's close enough.

Do something like this:

“c” will always hover around 5000, which is the expected if we assume it's a 1ms delay.

I know this is some amount of time, but its less than 0.001 seconds (1 ms)

define Tick

wait (0) secs

This is a timescale that is definitely above 0 seconds.
(edit:it hovers around 1/1500000 seconds to 1/2000000 seconds)
(edit:probably)