home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!usc!hela.iti.org!cs.widener.edu!eff!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uwm.edu!ogicse!news.u.washington.edu!stein.u.washington.edu!hlab
- From: sk4i+@andrew.cmu.edu (Samuel John Kass)
- Newsgroups: sci.virtual-worlds
- Subject: Re: TECH: U of I Call for Specification Discussion
- Message-ID: <1992Nov9.215900.10892@u.washington.edu>
- Date: 7 Nov 92 23:58:42 GMT
- Article-I.D.: u.1992Nov9.215900.10892
- References: <1992Nov6.034310.4526@u.washington.edu>
- Sender: news@u.washington.edu (USENET News System)
- Organization: University of Washington
- Lines: 21
- Approved: cyberoid@milton.u.washington.edu
- Originator: hlab@stein.u.washington.edu
-
-
- What I'm curious about is setting up the equivelant of an "AT Command
- Set" (with all due credit going to Hayes so they don't sue me, too) for
- any Virtual Reality product. Of course, it's going to be vastly
- different from said command set, but there at least needs to be the
- equivelent of a set of agreed upon "S" registers, polling, making a
- 'connection' (continuous polling), etc. A better analogy might be
- streams, where one can set up "connections" with any component, who's
- bitstream would be seperate from another's. But then we're talking
- about an entire network protocol.
- So, on the simple end there is the equivelent of the command set and
- S registers, and a couple modes, but that would only support the
- hardware it was designed for. On the other, we have an entire network
- protocol which would have the flexability to support ANYTHING
- (treadmills, speakers, and anything else you can think of) but would be
- an order of magnitude harder to design and program.
- --Sam
-
- -- Disclaimer: Everything is true. - sk4i+@andrew.cmu.edu --
- -- FM/SVS Software, Inc. - "Just a bunch of geeks driven by the Neato." --
- -- A Math/CS major at Carnegie Mellon University -- Beward the fnords. --
-