Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!munnari.oz.au!bunyip.cc.uq.oz.au!marlin.jcu.edu.au!eegeh
From: eegeh@marlin.jcu.edu.au (Glen Elliot Harris)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Virtual reality for the PC! (Sort of...*ahem*)
Message-ID: <1991Jun28.055051.1991@marlin.jcu.edu.au>
Date: 28 Jun 91 05:50:51 GMT
References: <0094AAC8.48F87280@MAPLE.CIRCA.UFL.EDU>,<1991Jun27.091344.21562@cavebbs.gen.nz> <0094AC65.E53F91C0@MAPLE.CIRCA.UFL.EDU>
Organization: James Cook University
Lines: 30

In <0094AC65.E53F91C0@MAPLE.CIRCA.UFL.EDU> sorrow@oak.circa.ufl.edu writes:

>On to another question....what is about the fastest method of updating 
>screens?  Has anyone managed to use "chopper" glasses and do animation
>at the same time?  It would entail updating 2 pages of video every 60th
>second.  Is this possible?  Anything slower would be out of the question
>since flicker would become tiresome.

>Brian Hook -- Specialist in X to ANSI.SYS porting software

  Well, If you used a 320x200 screen and had one screen per refresh, eg
one left/right pair per every two refresh, you would get a 30Hz
animation.  In 256 colors, that would be(get out the calculator)
320 x 200 x 60 = 3.84 million bytes.Some ET4000 cards can get up to this
video write rate, and my PowerGraph can do 5.3Mb/s.
  If you wanted to cut the animation down to 15 frame pairs per second,
you would be using the same amount of transfer, unless you played around
with the register that tells the cars where to start reading from in the
video ram. ie: write first frame, write second frame AFTER the end of
the first frame in memory, move pionter to second frame, wait, move
pointer to first frame, wait, move pointer to second frame.  While
waiting, you could be putting more frames in the video ram, ready for
display.
  This is a very memory hungry method of doing things, so an XMS memory
move directly to the screen memory, although it may be impossible to do
with the pointer method above, is _VERY_ fast, as 87 frames/s in
640x350x16 when moving 640x256 pixel screens shows.

Glen Harris
eegeh@marlin.jcu.edu.au