From: thinman@netcom.com (Lance Norskog)
Subject: Re: TECH: Virtual Reality Systems Discussion
Date: Thu, 24 Sep 92 14:07:55 PDT


} bobp@hal.com (Bob Pendelton) writes:
} 
} IN my copious :-) spare time I've been working on a similiar model.
} My first step was to find a good, freely redistributable scheme or
} lisp system. I've found ELK, which has the same copyright restrictions
} as X to be a good choice and I'm working on making it somewhat more
} suitable for my purposes.

Mmmm, tried ELK first.  It's a nice package, and Nixdorf paid
to write it and maintain it for in-house use.  This is always 
a good sign.  It's the best-documented Scheme of the bunch.

I brought up my stuff with SCM and wound up switching to DEC's
Scheme->C because I want compilation.  It looks fairly easy
to port Scheme->C to the 386 GCC DOS compiler.  (I want a 
distributable DOS binary for propoganda reasons.)

} After that I was planning to add support for 3D graphics (I have a
} fixpoint based 3d package I've hacked together over the years).
} Interactive I/O, and communications.

Cool!  A hint about 3D: informants say the fastest interactive
3D comes from keeping the viewpoint fixed, the background static,
and chopping the screen up into tiles.  Paint tiles that need
updating.  With VGA it's fairly easy to copy full rectangles of 
color C from off-screen video RAM to tile T.  You only need
to go to painter's algorithm or Z-buffering if a tile has more 
than one poly on it.

The stereo sound cards for the PC include independent synthesizers.
You just poke numbers once and leave them alone.  With a monitor
and two speakers pasted on the side, you can do nice effective
right-left placement of several compute-free sound channels.

} It looks like scheme continuations are a perfect way to model
} connection context for a client/server system.

Yes.  There's a nice threads package in the Scheme archive
on nexus.yorku.ca.  Includes pre-emptive scheduling.
You can download programs and run them safely because
of Scheme scoping.

} I'd steer clear of the dataflow stuff though. I prefer the idea of
} building "executable" structures that are executed to update the
} visual display. It looks like lazy evaluation can be used to control
} level of detail generated per time slice. Just keep going one level
} deeper until you run out of time...

I was planning to use C or incrementally compiled code exclusively
during the actual screen update; this was when I stuck with
interpreted Scheme.  The performance of compiled Scheme
(1/3 of C for a simple PI algorithm) is good enough that this
is an interesting idea.  By executable structures do you mean
Scheme programs or "executable data structures " as in the
Synthesis OS?

The important idea is that you download or load scripts which
don't get to actually do anything; they only create structures
down below which actually do the screen/sound/etc.  The 
separation of church and state, I mean policy and mechanism,
is the heart of any really good OS architecture.  And this
is a real-time operating system.