[Squeakland] drive-a-car newbie questions

[Ken Kahn]

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 at squeakland.org>
To: "Ken Kahn" <kenkahn at toontalk.com>; "Andreas Raab"
<andreas.raab at squeakland.org>; "Randy Heiland" <heiland at indiana.edu>;
"'Squeakland'" <squeakland at 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.
> >
> >1. 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?
> >
> >2. 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 at squeakland.org
> >http://squeakland.org/mailman/listinfo/squeakland
>
>
>