Hi all -
Thanks for remembering Director. For those interested in the history of these ideas read
Ken Kahn and Carl Hewitt. Dynamic graphics using quasi-parallelism. In Proceedings of the ACM/SIGGRAPH Conference, August 1978.
My focus back then was expressing animation at a high level (and the other part of the thesis was an AI system that generated animation). Graphical interactivity wasn't really feasible (on a time-shared PDP10). So simulation time was identical to replay time (much like how Pixar makes animations). Typically replay was accomplished by capturing each frame on film (though I also made flip books).
In ToonTalk there is special support for speed so that simulation time is identical to real time but in general you do a trick like Andreas mentioned -- "foo forward by (timer's elapsedTime * foo's speed)".
ToonTalk has a different, but also somewhat kludgey, way to have many cycles per tick. If a robot reads any sensor whose semantics is related to ticks then it only runs one cycle per tick, otherwise it can run as many times as it can within a time slice. So "pure" computations aren't slowed down by the tick mechanism.
Regarding Croquet's "interesting relationships between pseudotimelines and realtimelines" -- how can one find out more about that?
Best,
-ken kahn
----- Original Message ----- From: "Alan Kay" alan.kay@squeakland.org To: "Ken Kahn" kenkahn@toontalk.com; "Andreas Raab" andreas.raab@squeakland.org; "Randy Heiland" heiland@indiana.edu; "'Squeakland'" squeakland@squeakland.org Sent: Sunday, February 29, 2004 6:18 PM Subject: Re: [Squeakland] drive-a-car newbie questions
Hi Ken --
What tack did you take in your thesis (Andreas -- Ken`s thesis, called Director, was one of the first to use various kinds of clocks to tick processes along)?
Also, if you look in the menu in the etoy scriptor, there is an entry called "fires per tick". This is a somewhat kludgey but useful way of relating the animation time (ticks per second) to the number of times through a script per tick.Normally, these are 1:1, but can be as fast
as
10000:1, which is fast enough to write an etoy that will step through
and
play samples at audio rates (see the Sampling etoy).
And, the Croquet stuff we are doing uses some of Dave Reed`s ideas (he
is
one of the 3 main folks), and this involves some interesting
relationships
between pseudotimelines and realtimelines.
Cheers,
Alan
At 09:56 AM 2/29/2004, Ken Kahn wrote:
Andreas Raab wrote:
It is possible to treat it is a measure of speed by setting a script to ticking, effectively specifying that "each
tick we
move
by delta" and naturally, given the values for "tick" and "delta"
we
can
compute the speed by dividing tick into delta and we can influence
the
speed
by changing either tick or delta (for changing the "tick" you can click-and-hold on the little clock in the script; it will show you
a
little
menu where you can choose how fast this script should be ticking).
I have a few questions about this.
- So if a tick is a specified number of milliseconds then what
happens
when too much is happening during a cycle for the computer to be able
to
handle in "tick" milliseconds?
- Or instead if the tick is in Squeak time units what relationship
does
it have to the passage of time my watch shows?
Underlying my questions is the desire to be able to set a speed so
that
a car takes, for example, exactly 5 seconds to travel 100 units (pixels?) at a constant speed.
Best,
-ken kahn
Squeakland mailing list Squeakland@squeakland.org http://squeakland.org/mailman/listinfo/squeakland