fmgst@unix.cis.pitt.edu (Filip Gieszczykiewicz) (11/06/90)
(Let's try this again....)
Greetings. I will be getting my 386 in a few weeks and
am in the process of picking interesting things I want
to do. One of them would be an adaptation (limited)
of a simple VR platform.
I was thinking of something along these lines:
o 386 + large hard disk as a "server". This would be the center of
all the communication.
o A user (minimum 386/20 + EGA + 2 MB RAM + 40 MB 28ms HD)
would connect his computer to the server via ETHERNET.
He would initially get a disk with some simple program that
would attach him and download a graphics and I/O library from
the server. _That_ new program would be what would transform
his computer into a VR "world". For example, plans for an
office or (for testing and debugging reasons) a VR game.
o The library would consist of LINE drawing routines that could
draw simple, 3D, "objects" (houses, trees, people, dogs, and
cats, etc) in realtime. In other words, to (say) draw a
bare room, a desk, and you (the user) and some other person.
The server would send simple text commands that would be
interpreted by the resident graphics library. The text command
might, for example, be : "Draw desk (type) @ x,y,z" +
"Draw person (type) @ x,y,z doing (whatever defined)" + "etc."
It would be up to the resident library to actually draw those
objects in realtime. If this were not the case, Ethernet would
not be able to supply all the data fast enough for realtime
display for all the users attached. (One is no fun :-)
While thinking about this project, the question of debugging
came to my mind. Graphics are messy and to make things efficient,
one might have to sacrafice a little style - ie. count on tons
of errors that would have to be worked out.
I, a great while ago, played AberMud (sp?). It's a multi-user
game in which other players see you as you enter into their
view (in the game). This game could be used to test the
platform and only then could one concentrate on writing
something that does not exist currently (well...)
In other words: (to sum up the concept)
o You get a disk, put it in the machine, run a program which
attaches you to the VR server (world, office, game, whatever).
o Your computer downloads the _huge_ drawing library (this
could only be done once and saved to disk) and jump to
_that_ new program.
o The new program would initialize your computer and let the
server know who, what, and what-up-to you are. The server
would also let other users know what just took place.
(If applicable, it would draw "you" on their screens)
o The program, having been initialized, would wait for
your actions (various drivers could be developed for all
sorts of input devices. The idea is for an OPEN DESIGN where
anyone can adapt what they wish...)
o If anyone "moves", the server notifies your computer of
the change and your computer changes the screen accordingly.
(Note: The server does NOT transmit coordinate points for
all points in the picture. It does not even give screen by
screen locations of all objects. It simply lets your computer
know in what GENERAL direction things are changing... It would
be up to your computer to figure out what to do...)
o If you "move", your computer lets the server know. The server
then "tells" all the others what just happened and THEY do
all the new drawing.
o The server acts as a "hub". Since, for a limited number
of users, that's not an intensive task, many other features
can be implemented. For example, one can "talk" to another
user (Here, again, one could write a driver to output
that to a speech synthesizer and/or get input from a
voice recognition board.... OPEN DESIGN).
The reason for the 386/20 limit on computer hardware is the
fact that too many people are held back by the fact that they
feel that they have to support EVERYONE. Think about it,
realtime, 3D, VR on an IBM PC @ 4.77 MHz..... sad, yet,
that's what many have to do. Perhaps that could be lowered
to a 286/12 but I don't know.... :-)
Another reason for limiting to a specific series of
processor is the fact that not only can the compiler be
used to optimize for the faster execution, but also all of the
drivers and other high-speed graphics routines have to be
in assembly and it does not pay to write them in 8086
code if you can use 80386. I'm sure someone will do it... :-)
By the way, for 3D realtime (well, almost realtime), one is
required a MATH COPROCESSOR! (80486 has one built in)
Well, that's MY idea of what I think I'm going to write.
I am looking for SOLID input. However, references will be
welcome. I would especially like to hear about SIMPLE
protocol. I'll get sources for TELNET or FTP and see if
I can get ETHERNET to work...
I will be writing this in C for speed and ease of adding
assembly to it. I have yet to decide on brand of compiler
(Turbo (I know how to use) or MS (I don't))
I'd like to learn TC++, is this a good way of doing so?
Any comments, criticizms, flames? Send them to me and
I will make available the final result (collection).
Take care.
--
_______________________________________________________________________________
"The Force will be with you, always." It _is_ with me and has been for 10 years
Filip Gieszczykiewicz "... a Jedi does it with a mind trick... " ;-)
FMGST@PITTVMS or fmgst@unix.cis.pitt.edu "My ideas. ALL MINE!!"