[-empyre-] Games, histories and preservation

[Jim Andrews]

> There's nothing wrong with Directors timing structures (see my
> pieces here:  http://www.paul-brown.com/GALLERY/TIMEBASE/INDEX.HTM
> which should play stably over different platforms/cpus etc... [and
> note there is a mixture of Java and Director/Shockwave pieces linked
> from that page])  The problem was that - especially in the early days
> - people didn't use them correctly and resorted to using wait loops
> and other hacks to time work so performance was based on a specific
> platform/cpu.
>
> But - yes!  it's precisely this problem that makes emulation/
> reconstruction difficult.  Even i don't really remember what some of
> my early works looked like!

I agree. In time-based programming arts, time is somewhat slippery. You
can't simply assume that the machine/software will take care of it for you.
The programming has to be intelligent concerning the timing of events.

For instance, if you set Director at x fps, it won't necessarily play at
that speed on all machines. However, if you use timeOut objects and other
such constructs to regulate events, the thing will indeed play accurately on
machines fast enough and faster.

It seems that Director, Flash, and probably other dev platforms supply the
rudiments for accurate timing. Less than perspicuous programming will work
fine on the machines of its day. But to make something that'll last a bit
longer, you have to think about time a bit more deeply.

ja
http://vispo.com/jig