home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!mcsun!Germany.EU.net!mpifr-bonn.mpg.de!uniol!caty!cbmger!peterk
- From: peterk@cbmger.de.so.commodore.com (Dr Peter Kittel Germany)
- Newsgroups: comp.sys.amiga.graphics
- Subject: Re: 30 fps: Yeay or nay?
- Message-ID: <10388@cbmger.de.so.commodore.com>
- Date: 7 Jan 93 14:04:40 GMT
- References: <1992Dec28.224231.8344@fcom.cc.utah.edu> <1992Dec29.023929.6787@mnemosyne.cs.du.edu> <Blue-Knight.04t9@bknight.jpr.com> <1993Jan1.111915.4004@midway.uchicago.edu>
- Reply-To: peterk@cbmger.de.so.commodore.com (Dr Peter Kittel Germany)
- Organization: Commodore Germany
- Lines: 25
-
- In article <1993Jan1.111915.4004@midway.uchicago.edu> sjchmura@midway.uchicago.edu writes:
- >
- >We need, for fast anim playback the following:
- > Anim-7 (AAP_AAC) longword format used.
- > Be sure the data is aligned in 64bit format
-
- Sorry, don't know about this AAP_AAC or ANIM-7 format, but generally:
- Do you really think it would be a good move from 1 byte to longwords?
- See, you want to compress your data. Thus your goal is to find as many
- identical data as possible and store these only one time plus a count
- how many times you have to replicate them in the final picture. Now if
- your data size is 8 bits, the probability for (vertically) adjacent
- identical values is magnitudes higher than for longwords. I fear if you
- change to longwords you would have many more occurences of non-identities
- where you have to store new full data without any compression but still
- organizational overhead. So in the end, you would lose on compression
- effectivity and thus probably also on playback speed.
-
- But if this particular format is much smarter, then please forget my
- uttering and perhaps explain the trick used there.
-
- --
- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions...
- Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
- Wer's nicht kann, soll's bleiben klopfen oder Steine lassen!
-