Discuss Scratch
- Discussion Forums
- » Advanced Topics
- » Scratch timer, Accurate down to Tenth of a Second
- Andreto
- Scratcher
100+ posts
Scratch timer, Accurate down to Tenth of a Second
I found this on the show and tell page. https://scratch.mit.edu/projects/273365840/#player
It uses the
Is this a new idea or is it just a known method that I never heard of?
It uses the
(timer)along with the
(current[time])to make a clock accurate down to a Tenth of a Second.
Is this a new idea or is it just a known method that I never heard of?
- jokebookservice1
- Scratcher
1000+ posts
Scratch timer, Accurate down to Tenth of a Second
Well, the ‘current’ block isn't too precise, so it makes sense to exploit blocks like ‘days since 2000’ and ‘timer’. The issue with using ‘timer’ is that it's not guaranteed to be synchronised with the actual time, so if you start the project in the middle of a second, the millisecond component would be out-of-synch.
The project resolves this like so (simplified):
This block detects when the ‘current second’ block changes its value, which is the point where a second has just ended and hence the millisecond component is 0. Hence, reset the ‘timer’ so it also has a millisecond component of zero.
'days since 2000' has the (dis)advantage of being UTC.
Extracting the milliseconds from it doesn't line up with the ‘timer’ milliseconds (it's out by a fraction), but maybe that's okay because you can extract the seconds, etc. from ‘days since 2000’ too.
The project resolves this like so (simplified):
set [future time v] to ((current [second v]) + (1))
wait until <(current [second v]) = (future time)>
reset timer
This block detects when the ‘current second’ block changes its value, which is the point where a second has just ended and hence the millisecond component is 0. Hence, reset the ‘timer’ so it also has a millisecond component of zero.
'days since 2000' has the (dis)advantage of being UTC.
Extracting the milliseconds from it doesn't line up with the ‘timer’ milliseconds (it's out by a fraction), but maybe that's okay because you can extract the seconds, etc. from ‘days since 2000’ too.
- _nix
- Scratcher
1000+ posts
Scratch timer, Accurate down to Tenth of a Second
Ooh, I'm nitpicking here, but this won't work if more than a whole second passes between the times when Scratch executes these frames, e.g. lots of lag, or if the system time changes (maybe, try it yourself, don't quote me). Instead you'd want to do “not current second < future time”. Although..maybe I'm missing a point hereset [future time v] to ((current [second v]) + (1))
wait until <(current [second v]) = (future time)>
reset timer
This block detects when the ‘current second’ block changes its value, which is the point where a second has just ended and hence the millisecond component is 0.
══ trans autistic lesbian enbydoggirls // 16 17 18 19 20, she/they ════
sparrows one word to the paragraph // <3 // ~(quasar) nebula
- jokebookservice1
- Scratcher
1000+ posts
Scratch timer, Accurate down to Tenth of a Second
Ooh, I'm nitpicking here, but this won't work if more than a whole second passes between the times when Scratch executes these frames, e.g. lots of lag, or if the system time changes (maybe, try it yourself, don't quote me). Instead you'd want to do “not current second < future time”. Although..maybe I'm missing a point hereset [future time v] to ((current [second v]) + (1))
wait until <(current [second v]) = (future time)>
reset timer
This block detects when the ‘current second’ block changes its value, which is the point where a second has just ended and hence the millisecond component is 0.
If you have any lag (except an exact integer amount), the milliseconds will no longer line up with the timer and none of it works anyway!
- Andreto
- Scratcher
100+ posts
Scratch timer, Accurate down to Tenth of a Second
Ooh, I'm nitpicking here, but this won't work if more than a whole second passes between the times when Scratch executes these frames, e.g. lots of lag, or if the system time changes (maybe, try it yourself, don't quote me). Instead you'd want to do “not current second < future time”. Although..maybe I'm missing a point hereset [future time v] to ((current [second v]) + (1))
wait until <(current [second v]) = (future time)>
reset timer
This block detects when the ‘current second’ block changes its value, which is the point where a second has just ended and hence the millisecond component is 0.
If you have any lag (except an exact integer amount), the milliseconds will no longer line up with the timer and none of it works anyway!
This got technical quickly!
- MegaApuTurkUltra
- Scratcher
1000+ posts
Scratch timer, Accurate down to Tenth of a Second
I'd just use days since 2000. Timing loops that depend on relative time are prone to having small errors accumulate, and if you're trying to create absolute time out of a relative time loop, then if lag happens as _nix and jokebookservice are getting at, your time is going to be wrong until you restart the project. It's better to start off with absolute time sources from the beginning, like days since 2000. You can compare days since 2000 with current [x] to figure out the time zone offset.
$(".box-head")[0].textContent = "committing AT crimes since $whenever"
- 321321321john
- Scratcher
2 posts
Scratch timer, Accurate down to Tenth of a Second
when green flag clicked
set [ variable1] to (days since 2000) * (86400))
forever
set [ variable2] to [((days since 2000) * (86400(() - (variable1)))))]
end
Makes it to 3 decimals but put it in a text engine and it gives 15 decimals.
Last edited by 321321321john (Jan. 26, 2022 14:19:05)
- Discussion Forums
- » Advanced Topics
- » Scratch timer, Accurate down to Tenth of a Second