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