From: Dave Stampe-Psy+Eng <[email-masked]>
Date: Mon, 21 Oct 91 00:28:38 -0400

[email-masked] (John D Beutel) replies:

>That's what I'm wondering.  If the samples are made at a constant
>rate (like by the original hi-res routine), then are the samples that
>the glove makes itself limited by this?  I've listened to the clicks
>that the glove makes while being sampled at a constant speed,
>and I can't hear any difference between open and closed fingers.
>I'm not sure I can tell the difference between 13 and 17 Hz,
>but I suspect the glove has a constant sample rate when polled
>with the original method, independent of finger position.

Quite possible: I have'nt scoped the transmitter and glove read lines in
the glove myself.  I suspect that there *is* a small effect even if you read th
glove at a constant rate, in terms of how often the glove is readable.  What 
may happen is that the glove finishes reading the fingers ahead of time if
the hand is open, then starts the next cycle either when the cycle timer
expires (internal to the glove CPU) or it's asked for the data.  This explains
why you trash data if the glove is read too soon: there's nothing in the 
buffer yet to read, and the glove starts its next conversion cycle too soon.

>must be synchronized with the glove polling.  But, if the
>fingers are open and there's only 58 ms between polls,
>then that's all the time the graphics routines will have,
>so they must be able to do their job in 58 ms.  If the
>fingers are closed and there's 80 ms between polls, then
>the extra 22 ms will be wasted (unless the graphics can
>be written to do the minimum rendering in 58 ms and some
>worthwhile extra rendering if more time (up to 22 ms) happens
>to be available). 
>
>However, the whole point to sync'ing the code and the glove
>is to avoid an average 30 ms extra lag time, so if the
>original polling method adds any extra lag time to the
>quick-polling method, then it may not be worth sync'ing
>(or it may be worth accepting the wasted CPU time).
>
>--
>J. David Beutel  11011011  [email-masked]  "I am, therefore I am."

True, but the AVERAGE delay is reduced by reading the glove as fast as 
possible.  In all likelihood it's going to be difficult to lock the
video rendering to the glove read rate anyway, and the system will be
asynchronous.  If you double-buffer the video, the renderer ends up
syncronized with the vertical sync of the video card (16.7 mS), so you have
to choose between 4 (66.6mS) and 5 (83.3mS) display periods anyway.

The REAL problem is going to be doing a decent job of rendering in the 
available time.  It takes 82mS just to access each pixel once on a 320x200x256
color IBM PC mode picture in assembly language (some cards may be faster)
although clearing it can be done in 22mS by reprogramming the hardware.  THat
means that unless wireframe graphics are used, we may have to use a lower
resolution mode such as 320x200x16 color.  Of course, partial screen updates
reduce the time, but if the system uses eyephones, pretty much the whole
scene must be redrawn when the user's head moves.

In case you're not using an IBM, video access is less of a problem.  However,
the problem now becomes the other stages of rendering: deciding what gets
shown and what is hidden.  Assuming a "world" database of 3000 polygons, at
LEAST 90% may have to be eliminated before rendering starts, so CPU power
comes into the picture.  Object-level clipping, partial screen updates, and
scan-line drawing algorithms are just some of techniques that will be 
needed.  (Scan-line algorithms attempt to access each pixel on the screen once
per drawing.)

As you can see, I'm thinking mostly about graphics problems right now.  Issues
such as how to represent polys, how many colors to use, Gorand shading and
texturized objects (and other future considerations) depend on the type
of rendering system chosen, as well as processor power and graphics hardware
of the computer.  BTW, using Gourand shading and textureing are practical, 
but both take a 30-40% "hit" in rendering performance.  I'll try to throw
up test ideas every now and then... I REALLY appreciate the feedback I'm
getting on this.

- Dave Stampe