[-empyre-] Games, histories and preservation
julian at selectparks.net
Wed Mar 19 22:18:45 EST 2008
..on or around Wed, Mar 19, 2008 at 02:23:36PM +1000, Paul Brown said:
> On 19 Mar 2008, at 00:51, Julian Oliver wrote:
>> i remember seeing the Australia Council throw large swathes of cash at
>> CDROM based art in the mid-to-late 90's, most of which was made using
>> the proprietary Macromedia Director.
>> nowadays there are very few Director-based projects made more than a
>> years ago that function properly on modern hardware. this is due to
>> Director's internal time structure being (it seems to me) metered on
>> basis of CPU clock-cycles, not system time. this means any animation
>> will play too fast and any event management implicating timed events
>> will be grossly out-of-sync.
> As someone who has been using Director since it first appeared in the
> late 1980's (as VideoWorks) I'd just like to post a point of order here.
> 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.
ahah, it's good to know that poor programming was at fault and not
Director itself. i've seen several time-broken pieces made in that
program and guessed that something must have been very wrong with the
way Director dealt with time.
> 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!
funny that in these cases it's time itself that needs conserving. time
will eat itself etc..
messages containing HTML will not be read.
More information about the empyre