This is related to the discussion of non-accurate tick rates: http://tracker.squeakland.org/browse/SQ-708
There currently is no good way to measure real time in Etoys. The Clock object is only accurate to one second.
So I'm proposing to have a global timer, in seconds, but with milli-second resolution. There would be a tile for accessing it in the world's "playfield" category (actually any playfield / holder).
This would allow to do animations etc to proceed in real time, independent of the actual tick rate of a script.
I just posted a proposed implementation to the inbox (Etoys-bf.31). Also, find attached an example project.
Would that be generally useful?
- Bert -
Bert, Yes! It is very useful, I like it. Kathleen
---- Original message ----
Date: Sat, 26 Jun 2010 18:16:24 +0200 From: Bert Freudenberg bert@freudenbergs.de Subject: [etoys-dev] Timers To: etoys-dev@squeakland.org
This is related to the discussion of non-accurate tick rates: http://tracker.squeakland.org/browse/SQ-708
There currently is no good way to measure real time in Etoys. The Clock object is only accurate to one second.
So I'm proposing to have a global timer, in seconds, but with milli-second resolution. There would be a tile for accessing it in the world's "playfield" category (actually any playfield / holder).
This would allow to do animations etc to proceed in real time, independent of the actual tick rate of a script.
I just posted a proposed implementation to the inbox (Etoys-bf.31). Also, find attached an example project.
Would that be generally useful?
- Bert -
TimerTest.001.pr (44k bytes) ________________ _______________________________________________ etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
Yes useful, has my vote.
I like that each playfield has its own timer, which allows for multiple timers and that you can reset them.
1. Assuming inclusion in the next release for documentation purposes at what point does the timer roll over? 2. Hmmm, I added two playfields and brought watchers for their timers out for display (about 41 seconds apart), then I saved the project and re-opened it and the values before save were about 40 and 81. On closing Etoys and re-opening the project, the timer values increaded to ~1073635 and 1073686 (still maintaining the 41 second difference, but I saw the numbers jump on open from 40, 81 to the big numbers. 3. On project open do the timers keep their values from last save, it seems that is what happened with TimerTest.001.pr 4. The timers do not seem to start until you open the Viewer and select the category playfield which is seems fine for all object with a playfield category is this the same for World's timer?
Stephen
On Sat, Jun 26, 2010 at 12:16 PM, Bert Freudenberg bert@freudenbergs.dewrote:
This is related to the discussion of non-accurate tick rates: http://tracker.squeakland.org/browse/SQ-708
There currently is no good way to measure real time in Etoys. The Clock object is only accurate to one second.
So I'm proposing to have a global timer, in seconds, but with milli-second resolution. There would be a tile for accessing it in the world's "playfield" category (actually any playfield / holder).
This would allow to do animations etc to proceed in real time, independent of the actual tick rate of a script.
I just posted a proposed implementation to the inbox (Etoys-bf.31). Also, find attached an example project.
Would that be generally useful?
- Bert -
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
On 27.06.2010, at 04:19, Steve Thomas wrote:
Yes useful, has my vote.
I like that each playfield has its own timer, which allows for multiple timers and that you can reset them.
• Assuming inclusion in the next release for documentation purposes at what point does the timer roll over?
About 300 hours (1073741823 milliseconds) after you reset it to 0.
• Hmmm, I added two playfields and brought watchers for their timers out for display (about 41 seconds apart), then I saved the project and re-opened it and the values before save were about 40 and 81. On closing Etoys and re-opening the project, the timer values increaded to ~1073635 and 1073686 (still maintaining the 41 second difference, but I saw the numbers jump on open from 40, 81 to the big numbers.
The timers are not reset on project loading. There currently is no overhead to timers.
Unless you use a timer in a script or look at its value, the current value is not computed.
There is a tiny space overhead to store the offset between the timer and real time. It's marginal. But that is why I made only playfield-like objects expose it, rather than showing it for every object.
• On project open do the timers keep their values from last save, it seems that is what happened with TimerTest.001.pr
They get a random value on project load.
• The timers do not seem to start until you open the Viewer and select the category playfield which is seems fine for all object with a playfield category is this the same for World's timer?
In my implementation, timers are created on demand. Only the instant you look at a playfield's viewer is its timer created.
I think I should change the behavior to always start out with a random value. Then it's clear that it's the user's responsibility to reset it to a known value. If they care, that is - e.g. my example project did not need that).
And to answer Subbu's and your follow-up questions:
Why a timer variable on each playfield as opposed to a timer object?
It's more general, less overhead. You could easily build a timer object in Etoys given the basic functionality I added there.
It fits well with the mouse coordinates I thought.
The timer object could also be a stopwatch (yes, you could create a variable and set it to the timer value on some event, but a 'stop timer' tile seems simpler). Also, you would only have running intentionally created timers, the current implementation would cause timers to run which could impact performance (albiet minimally).
Behind the scenes there are no individually "running timers". It's using the Squeak timer which is running anyway.
My implementation has no performance overhead whatsoever. Unless you use a timer in a script or look at its value, the current value is not computed.
There is a tiny space overhead to store the offset between the object timer and the Squeak timer. It's marginal. But that is why I made only playfield-like objects expose it, rather than showing it for every object. It's still available for any object. You could actually use the world's timer tile and replace "world" with any object tile to get a per-object timer.
- Bert -
On 27.06.2010, at 11:31, Bert Freudenberg wrote:
On 27.06.2010, at 04:19, Steve Thomas wrote:
at what point does the timer roll over?
About 300 hours (1073741823 milliseconds) after you reset it to 0.
The timers are not reset on project loading. There currently is no overhead to timers.
Unless you use a timer in a script or look at its value, the current value is not computed.
There is a tiny space overhead to store the offset between the timer and real time. It's marginal. But that is why I made only playfield-like objects expose it, rather than showing it for every object.
• On project open do the timers keep their values from last save, it seems that is what happened with TimerTest.001.pr
They get a random value on project load.
Well not actually "random" as you might have guessed, they simply are not adjusted on loading.
• The timers do not seem to start until you open the Viewer and select the category playfield which is seems fine for all object with a playfield category is this the same for World's timer?
In my implementation, timers are created on demand. Only the instant you look at a playfield's viewer is its timer created.
I think I should change the behavior to always start out with a random value. Then it's clear that it's the user's responsibility to reset it to a known value. If they care, that is - e.g. my example project did not need that).
Thinking about it I have an idea that would be even simpler. I won't even create that "timer offset" (which is the only data required for supporting per-objec timers) until you *set* it. That is, looking at the value would not create anything. What you see would be just the number of seconds since starting up Etoys (that's how the underlying Squeak timer works). Only when you set it to another value, the difference between the Squeak timer and the object timer would need to be stored. Hmm, I like that.
Yet simpler would be to have just a global timer on the world without being able to reset it. That would require no state at all.
- Bert -
On Sunday 27 Jun 2010 6:26:28 pm Bert Freudenberg wrote:
Yet simpler would be to have just a global timer on the world without being able to reset it. That would require no state at all.
+1. Once timer is exposed as a World variable (like lastKeystroke), other types of timers (count-down, count-up etc.) can be easily derived from it through variable and scripts.
Subbu
Why a timer variable on each playfield as opposed to a timer object? The timer object could also be a stopwatch (yes, you could create a variable and set it to the timer value on some event, but a 'stop timer' tile seems simpler). Also, you would only have running intentionally created timers, the current implementation would cause timers to run which could impact performance (albiet minimally).
Stephen
On Sat, Jun 26, 2010 at 12:16 PM, Bert Freudenberg bert@freudenbergs.dewrote:
This is related to the discussion of non-accurate tick rates: http://tracker.squeakland.org/browse/SQ-708
There currently is no good way to measure real time in Etoys. The Clock object is only accurate to one second.
So I'm proposing to have a global timer, in seconds, but with milli-second resolution. There would be a tile for accessing it in the world's "playfield" category (actually any playfield / holder).
This would allow to do animations etc to proceed in real time, independent of the actual tick rate of a script.
I just posted a proposed implementation to the inbox (Etoys-bf.31). Also, find attached an example project.
Would that be generally useful?
- Bert -
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
On Saturday 26 Jun 2010 9:46:24 pm Bert Freudenberg wrote:
So I'm proposing to have a global timer, in seconds, but with milli-second resolution. There would be a tile for accessing it in the world's "playfield" category (actually any playfield / holder).
Shouldn't Timer be an global entity, like keyboard strokes? Playfields could use a separate object (say StopWatch) to track intervals.
Subbu
etoys-dev@lists.squeakfoundation.org