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)