Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-lcc!ames!ucla-cs!sdcrdcf!trwrb!cadovax!keithd
From: keithd@cadovax.UUCP (Keith Doyle)
Newsgroups: comp.sys.amiga
Subject: Juggler Workings
Message-ID: <1284@cadovax.UUCP>
Date: Mon, 5-Jan-87 13:33:08 EST
Article-I.D.: cadovax.1284
Posted: Mon Jan  5 13:33:08 1987
Date-Received: Tue, 6-Jan-87 20:39:15 EST
References: <345@neoucom.UUCP>
Reply-To: keithd@cadovax.UUCP (Keith Doyle)
Organization: Contel Business Systems, Torrance, CA
Lines: 26

Keywords:


[....]

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'd like to adapt it to be a generalized
'page flip' program that would work with files I might construct with
DPaint or whatever.  Are you using the blitter to get the reputed 30ms
decompression?  How?  Can this algorithm be effectively adapted such
that the source compressed data is in fast ram instead of chip ram?
If the blitter is being used, how much overhead might there be to move
10k from fast ram to chip ram?  

Lesse... 8MB / 10k.... that's 819 frames.  Oh boy, page flipping through
819 frames!  34 seconds of nonstop animation at 24 frames/sec.  Jeez, I'm
gonna need tons of hard disk.  How do you back up an 8MB file?  Give it
to friends on floppies?  Yow, am I having fun yet?

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?

Keith Doyle
#  {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd
#  cadovax!keithd@ucla-locus.arpa
"You'll PAY to know what you REALLY want!"