Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!certes.UUCP!doug From: doug@certes.UUCP Newsgroups: comp.sys.amiga Subject: IFF ANIM doc, StereoCape 3D, VideoScape 3D, LIVE paleontology Message-ID: <8707081106.AA14611@unisoft.UNISOFT> Date: Wed, 8-Jul-87 07:11:43 EDT Article-I.D.: unisoft.8707081106.AA14611 Posted: Wed Jul 8 07:11:43 1987 Date-Received: Sat, 11-Jul-87 02:54:56 EDT Sender: uucp@ucbvax.BERKELEY.EDU Lines: 248 [Dear LineEater: I live at ucbvax!unisoft!certes!doug; "reply" doesn't work!] The new IFF ANIM form is out...Allen Hastings says that it has been recently registered with Commodore, but possibly too recently for it to be part of the IFF docs. For those of you who want to know *now*, here's a description of it (I got this off FAUG disk #49, released tonight). I appended a line marking the end of the document, so you'll know whether you got the whole thing or not. Document follows signature below. Some "BTW" comments: A demo made with Videoscape 3D is also now making the rounds on BBS's and PD disks. And Leo showed his stereoscopic 3D hacks at the meeting, using the StereoTek glasses interfaced to the Amiga. Fun! When I first posted the news about these glasses (interfaced to the ST) months ago, George Robbins was kind enough to offer some comments about how an Amiga interface could work. Sure enough, that's exactly what Leo & Gary & Co. have done...it plugs into mouse port two to sync with the frame rate. Leo also says that his response to the BADGE Killer Demo Contest will *not* be stereoscopic (awww!!) because they'd have to distribute the glasses with every PD disk that carried the winners. Hmmm, now *there's* an idea! Wendy ("my name is NOT A-Squared!" but could've fooled me) says that the bottom line about why LIVE had so many problems is that: A-Squared designed it, and sold the manufacturing rights to Commodore, who then sat on it and apparently refused (?) to make and ship the d*mn things. A-Squared then worked for lo, these many months, to get the rights back. Never mind recent history; at least that partially explains ancient history. Perhaps everybody already knew all this, but it was news to me. (I still don't know why it was then transferred to GRAB after A-Squared was supposedly making it.) Doug Merritt ucbvax!unisoft!certes!doug /************************** CUT HERE *********************************/ >>> NEW IFF ANIMATION FORM: ANIM <<< A N I M An IFF Format For CEL Animations June 18, 1987 prepared by: Sparta Inc. 23041 de la Carlota Laguna Hills, Calif 92653 714) 768-8161 contact: Gary Bonham also by: Aegis Development Co. 2115 Pico Blvd. Santa Monica, Calif 90405 213) 392-9972 1.0 Introduction The ANIM IFF format was developed at Sparta originally for the production of animated video sequences on the Amiga computer. The intent was to be able to store, and play back, sequences of frames and to minimize both the storage space on disk (through compression) and playback time (through efficient de-compression algorithms). It was desired to maintain maximum compatibility with existing IFF formats and to be able to display the initial frame as a normal still IFF picture. The basic ANIM format described here has been in use for over a year in-house at Sparta with the XOR mode. The delta mode is a recent, and very effective, addition/improvement. 1.1 IFF File Format Overview The general philosophy of ANIMs is to present the initial frame as a normal, run-length-encoded, IFF picture. Subsequent frames are then described by listing only their differences from a previous frame. Normally, the "previous" frame is two frames back as that is the frame remaining in the hidden screen buffer when double-buffering is used. To better understand this, suppose one has two screens, called A and B, and the ability to instantly switch the display from one to the other. The normal playback mode is to load the initial frame into A and duplicate it into B. Then frame A is displayed on the screen. Then the differences for frame 2 are used to alter screen B and it is displayed. Then the differences for frame 3 are used to alter screen A and it is displayed, and so on. Note that frame 2 is stored as differences from frame 1, but all other frames are stored as differences from two frames back. ANIM is an IFF FORM and its basic format is as follows (this assumes the reader has a basic understanding of IFF format files): FORM ANIM . FORM ILBM first frame . . BMHD normal type IFF data . . CMAP . . BODY . FORM ILBM frame 2 . . ANHD animation header chunk . . DLTA delta mode data . FORM ILBM frame 3 . . ANHD . . DLTA ... The initial FORM ILBM can contain all the normal ILBM chunks, such as CRNG, etc. The BODY will normally be a standard run-length-encoded data chunk (but may be any other legal compression mode as indicated by the BMHD). The subsequent FORMs ILBM contain an ANHD, instead of a BMHD, which duplicates some of BMHD and has additional parameters pertaining to the animation frame. The DLTA chunk contains the data for the two available delta compression modes. If the older XOR compression mode is used, then a BODY chunk will be here. In addition, other chunks may be placed in each of these as deemed necessary (and as code is placed in player programs to utilize them). A good example would be CMAP chunks to alter the color palette. A basic assumption in ANIMs is that the size of the bitmap, and the display mode (e.g. HAM) will not change through the animation. 1.2 Recording ANIMs To record an ANIM will require three bitmaps - one for creation of the next frame, and two more for a "history" of the previous two frames for performing the compression calculations (e.g. the delta mode calculations). There are three frame-to-frame compression methods currently defined: 1.2.1 XOR mode This mode is the original and is included here for compatibility with some programs which still can output this mode. In general, the delta modes are far superior. The creation of XOR mode is quite simple. One simply performs an exclusive-or (XOR) between all corresponding bytes of the new frame and two frames back. This results in a new bitmap with 0 bits wherever the two frames were identical, and 1 bits where they are different. Then this new bitmap is saved using run-length-encoding. A major obstacle of this mode is in the time consumed in performing the XOR upon reconstructing the image. 1.2.2 Long Delta mode This mode stores the actual new frame long-words which are different, along with the offset in the bitmap. The exact format is shown and discussed in section 2 below. Each plane is handled separately, with no data being saved if no changes take place in a given plane. Strings of 2 or more long-words in a row which change can be run together so offsets do not have to be saved for each one. Constructing this data chunk usually consists of having a buffer to hold the data, and calculating the data as one compares the new frame, long-word by long-word, with two frames back. 1.2.3 Short Delta mode This mode is identical to the Long Delta mode except that short-words are saved instead of long-words. In most instances, this mode results in a smaller DLTA chunk. The Long Delta mode is mainly of interest in improving the playback speed when used on a 32-bit 68020 Turbo Amiga. 1.3 Playing ANIMs Playback of ANIMs will usually require two buffers, as mentioned above, and double-buffering between them. The frame data from the ANIM file is used to modify the hidden frame to the next frame to be shown. When using the XOR mode, the usual run- length-decoding routine can be easily modified to do the exclusive-or operation required. Note that runs of zero bytes, which will be very common, can be ignored, as an exclusive or of any byte value to a byte of zero will not alter the original byte value. 2.0 Chunk Formats 2.1 ANHD Chunk The ANHD chunk consists of the following data structure: UBYTE operation (=0 set directly, =1 XOR mode, =2 Long Delta mode, =3 Short Delta mode) UBYTE mask (XOR mode only - plane mask where each bit is set =1 if there is data and =0 if not.) UWORD w,h (XOR mode only - width and height of the area represented by the BODY to eliminate unnecessary un-changed data) WORD x,y (XOR mode only - position of rectangular area representd by the BODY) ULONG abstime (currently unused - timing for a frame relative to the time the first frame was displayed - in jiffies (1/60 sec)) ULONG reltime (timing for frame relative to time previous frame was displayed - in jiffies (1/60 sec)) UBYTE interleave (unused so far - indicates how may frames back this data is to modify. =0 defaults to indicate two frames back (for double buffering). =n indicates n frames back. The main intent here is to allow values of =1 for special applications where frame data would modify the immediately previous frame) UBYTE pad[21] (this is a pad for future use for future compression modes. Some of these - maybe 16 - are intentionally provided for use by Jim Kent for operation codes for each plane and other ancillary data he requested) 2.2 DLTA Chunk This chunk is a basic data chunk used to hold the delta compression data. The minimum size of this chunk is 32 bytes as the first 8 long-words are byte pointers into the chunk for the data for each of up to 8 bitplanes. The pointer for the plane data starting immediately following these 8 pointers will have a value of 32 as the data starts in the 33-rd byte of the chunk (indes value of 32 due to zero-base indexing). The data for a given plane consists of groups of data words. In Long Delta mode, these groups consist of both short and long words - short words for offsets and numbers, and long words for the actual data. In Short Delta mode, the groups are identical except data words are also shorts so all data is short words. Each group consists of a starting word which is an offset. If the offset is positive then it indicates the increment in long or short words (whichever is appropriate) through the bitplane. In other words, if you were reconstructing the plane, you would start a pointer (to shorts or longs depending on the mode) to point to the first word of the bitplane. Then the offset would be added to it and the following data word would be placed at that position. Then the next offset would be added to the pointer and the following data word would be placed at that position. And so on... The data terminates with an offset equal to 0xFFFF. A second interpretation is given if the offset is negative. In that case, the absolute value is the offset+2. Then the following short-word indicates the number of data words that follow. Following that is the indicated number of contiguous data words (longs or shorts depending on mode) which are to be placed in contiguous locations of the bitplane. If there are no changed words in a given plane, then the pointer in the first 32 bytes of the chunk is =0. /**************************** END OF DOCUMENT ************************/