Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!hplabs!felix!trwrb!cadovax!keithd
From: keithd@cadovax.UUCP (Keith Doyle)
Newsgroups: comp.sys.amiga
Subject: Re: Juggler Workings
Message-ID: <1312@cadovax.UUCP>
Date: Fri, 9-Jan-87 17:37:01 EST
Article-I.D.: cadovax.1312
Posted: Fri Jan  9 17:37:01 1987
Date-Received: Sun, 11-Jan-87 22:53:42 EST
References: <345@neoucom.UUCP> <1284@cadovax.UUCP> <1218@cbmvax.cbmvax.cbm.UUCP>
Reply-To: keithd@cadovax.UUCP (Keith Doyle)
Organization: Contel Business Systems, Torrance, CA
Lines: 19

In article <1218@cbmvax.cbmvax.cbm.UUCP> grr@cbmvax.UUCP (George Robbins) writes:
>In article <1284@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes:
>>The startup message on the Juggler program implies that the individual
>>frames take up 10k and are decompressed on the fly.  If this is true,
>>is the compression/decompression mechanism proprietary or can we be
>>let in on this little trick?
>I don't know for sure, but I suspect that only the region around the parts
>of the scene that change are updated, perhaps some kind of differential
>encoding?

Well, except for the fact that there are a couple of spots way out in the
ground-plane checkerboard that change slightly (possibly from the file
glitches that occured thru xmission).  This makes me think that the entire
screen may be being updated, not just a section in the middle where
movement is taking place.

Keith Doyle
#  {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd
#  cadovax!keithd@ucla-locus.arpa