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!"