[-empyre-] Games, histories and preservation

Julian Oliver 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 
>> few
>> years ago that function properly on modern hardware. this is due to
>> Director's internal time structure being (it seems to me) metered on 
>> the
>> 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..

-- 
julian oliver
http://julianoliver.com
http://selectparks.net
messages containing HTML will not be read.


More information about the empyre mailing list