RE: Zektor for the masses

>Less than a dozen pieces of information to convey
>every 40th of a second. Across a 28.8 modem, that'd give you
>(28800/(40*8))=90 bytes of data to pack all dozen objects from a frame
>of the gameplay.

Hey, we're talking about stuff I do for a job now... Weird. :-)

I gave a talk at the Computer Game Developer's Conference two years ago
about multi-player modem enabled gaming. We were doing a lot of
development at the time on SVD (Simultaneous Voice and Data) and DSVD
(Digital Simultaneous Voice and Data) and low-latency protocols for gaming.
(We named it "Fast Action/Reaction Technology" for the CGDC. The acronym
got a good laugh. ;-)

9600bps with no protocols makes a lot of sense for old video games. The
problem with 28.8K and any of the "modern" protocols is that the
V.42/V.42bis engines (error correction and compression) introduce a weird
variable timing thing. 9600bps with no error correction or data
compression makes for a nice predictable stream with few if any errors.
Your real-world throughput is about 1000bytes/sec which makes for around 24
bytes/frame at the G-80 refresh rate of 40Hz.

>By the way, from a perception perspective once delays get beyond a
>quarter second, then the players start complaining. Sorta like phone
>echo.

Right, the human brain doesn't resolve down to time slices much less than
33ms very well, so anything faster than that is generally "better". Still
though, depending on the display device, frame rates less than 30fps are
still very acceptable depending on the medium-- longer persistance
phosphors in games like the Vectrex and mono-monitors let you get away with
slower update rates, and the "glow" from a theater's silver screen lets the
shuttered 24fps movie rates look good to most everyone.

>Again, so there's a technical part of this email, would a Sega monitor
>be able to handle all the extra vectors for 4 extra players?

I wouldn't worry much about the monitor. As long as the data will fit into
the VRAM the vector generator can execute it. With a little careful
programming you can avoid most "worst case" distributions of the graphics
which helps prevent those big "instantaneous" jumps in beam position that
cause the monitors grief with the slew rate.

The thing to do for sending the data is to tailor your coding to the
application at hand. Rather than resending a bunch of 2-byte player/bullet
coordinates, since you're running lock-step with the frame rate anyway,
just send the delta's. (So if "vmax" for a ship is +/- 4 "pixels" encode
that information into 3 bits of a byte, like:

Bit 7 6 5 4 3 2 1 0
    - - ? X X ? Y Y

Where:
    - = don't care
    ? = sign (+/-)
  X X = x position delta from last position
  Y Y = y position delta from last position

Use the "don't care" byte to signify a particular packet type (like played
dead or alive, or next byte is to be handled as a special case or
whatever.)

That can keep your data density really low and let you run over a slower
line and with a slower DTE rate on the hose computer. (38,400 bps to keep
up with a 28.8 line would probably eat all the Z-80's time just moving
data!)

Oh, well, it's interesting to ponder how it could work, anyway... :-)

-Clay

Clayton N. Cowgill Engineering Manager
_______________________________________________________________________
/\ Diamond Multimedia Systems, Inc. clay@supra.com
\/ Communications Division http://www.supra.com/
Received on Thu May 22 16:08:44 1997