keithd@cadovax.UUCP (Keith Doyle) (01/05/87)
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!"grr@cbmvax.cbm.UUCP (George Robbins) (01/07/87)
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)
rico@oscvax.UUCP (01/09/87)
In article <1284@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: > [edited] >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? > .... Something just dawned on me that makes me even more impressed with the Juggler program's decompressing. All of the decompressing is happening while a HAM picture is being displayed. Think about that for a minute, HAM pictures have 6 (count'em) bit planes! There isn't very much memory bandwidth left when using 6 bitplanes. In fact, if I remember correctly, the CPU can only run during horizontal and vertical retrace. Now that uncompressing thing must really be doing something slick (or something dirty -- or is that the same thing :-) ). The canonical compression method (xor frame n with frame n+1 and run length encode the "difference") probably isn't good enough for this. So tell us how you did it already... the suspense is killing me! -Rico
keithd@cadovax.UUCP (Keith Doyle) (01/10/87)
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
jesup@steinmetz.steinmetz.UUCP (Randell Jesup) (01/12/87)
In article <1312@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: >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. Actually, it is doing changes only. Try holding down the right mouse button while the juggler is running. It also shows you the double buffering. Randell Jesup jesup@steinmetz.uucp (seismo!rochester!steinmetz!jesup) jesup@ge-crd.arpa