Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!sri-unix!hplabs!sdcrdcf!burdvax!bpa!cbmvax!grr From: grr@cbmvax.cbm.UUCP (George Robbins) Newsgroups: comp.sys.amiga Subject: Re: Juggler Workings Message-ID: <1218@cbmvax.cbmvax.cbm.UUCP> Date: Wed, 7-Jan-87 02:59:53 EST Article-I.D.: cbmvax.1218 Posted: Wed Jan 7 02:59:53 1987 Date-Received: Wed, 7-Jan-87 23:18:24 EST References: <345@neoucom.UUCP> <1284@cadovax.UUCP> Reply-To: grr@cbmvax.UUCP (George Robbins) Organization: Commodore Technology, West Chester, PA Lines: 22 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? >And either someone said or the startup message claims there are 12 frames, >though I count 24 from one ball position to the next. I think there are >24. Am I wrong? 24 sounds reasonable - I guessed fewer, but that was before I found out about the speed control with the numeric pad. -- George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)