ANIM IFF CEL Animations - Revision history

Costel Mincea: Text replacement - "" to ""

2025-01-26T19:30:52Z

Text replacement - "<syntaxhighlight>" to "<syntaxhighlight lang="C" line>"

← Older revision		Revision as of 19:30, 26 January 2025
Line 229:		Line 229:
	routine.		routine.

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	SetDLTAshort(bm,deltaword)		SetDLTAshort(bm,deltaword)
	struct BitMap *bm;		struct BitMap *bm;
Line 671:		Line 671:
	Here is the format of the DPAN chunk:		Here is the format of the DPAN chunk:

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	typedef struct {		typedef struct {
	UWORD version; /* current version=4 */		UWORD version; /* current version=4 */
Line 685:		Line 685:
	Here is the ANHD chunk format:		Here is the ANHD chunk format:

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	typedef struct {		typedef struct {
	UBYTE operation; /* =0 set directly		UBYTE operation; /* =0 set directly
Line 717:		Line 717:

	for Anim Brushes, I set:		for Anim Brushes, I set:
	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	animHdr.operation = 5; /* RIFF encoding */		animHdr.operation = 5; /* RIFF encoding */
	animHdr.interleave = 1;		animHdr.interleave = 1;

Steven Solie: /* ANIM.brush */

2013-07-08T22:00:07Z

ANIM.brush

← Older revision		Revision as of 22:00, 8 July 2013
Line 625:		Line 625:
	From a description by the author of DPaint, Dan Silva, Electronic Arts.		From a description by the author of DPaint, Dan Silva, Electronic Arts.

	The "Anim Brushes" of DPaint III are saved on disk in the IFF "ANIM"		The "Anim Brushes" of DPaint III are saved on disk in the IFF "ANIM" format. Basically, an ANIM Form consists of an initial ILBM which is the first frame of the animation, and any number of subsequent "ILBM"S (which aren't really ILBM's) each of which contains an ANHD animation header chunk and a DLTA chunk comprised of the encoded difference between a frame and a previous one.
	format. Basically, an ANIM Form consists of an initial ILBM
	which is the first frame of the animation, and any number of
	subsequent "ILBM"S (which aren't really ILBM's) each of which
	contains an ANHD animation header chunk and a DLTA chunk
	comprised of the encoded difference between a frame and a previous one.

			To use ANIM terminology (for a description of the ANIM format, see the IFF Anim Spec, by Gary Bonham). Anim Brushes use a "type 5" encoding, which is a vertical, byte-oriented delta encoding (based on Jim Kent's RIFF). The deltas have an interleave of 1, meaning deltas are computed between adjacent frames, rather than between frames 2 apart, which is the usual ANIM custom for the purpose of fast hardware page-flipping. Also, the deltas use Exclusive Or to allow reversable play.
	To use ANIM terminology (for a description of the ANIM format,
	see the IFF Anim Spec, by Gary Bonham). Anim Brushes use a "type
	5" encoding, which is a vertical, byte-oriented delta encoding
	(based on Jim Kent's RIFF). The deltas have an interleave of 1,
	meaning deltas are computed between adjacent frames, rather than
	between frames 2 apart, which is the usual ANIM custom for the
	purpose of fast hardware page-flipping. Also, the deltas use
	Exclusive Or to allow reversable play.

			However, to my knowledge, all the existing Anim players in the Amiga world will only play type 5 "Anim"s which have an interleave of 0 (i.e. 2) and which use a Store operation rather than Exclusive Or, so no existing programs will read Anim Brushes anyway. The job of modifying existing Anim readers to read Anim Brushes should be simplified, however.
	However, to my knowledge, all the existing Anim players in the Amiga
	world will only play type 5 "Anim"s which have an interleave of 0 (i.e. 2)
	and which use a Store operation rather than Exclusive Or, so no existing
	programs will read Anim Brushes anyway. The job of modifying existing
	Anim readers to read Anim Brushes should be simplified, however.

	Here is an outline of the structure of the IFF Form output by		Here is an outline of the structure of the IFF Form output by DPaint III as an "Anim Brush". The IFF Reader should of course be flexible enough to tolerate variation in what chunks actually appear in the initial ILBM.
	DPaint III as an "Anim Brush". The IFF Reader should of course be
	flexible enough to tolerate variation in what chunks actually
	appear in the initial ILBM.

	FORM ANIM		FORM ANIM
Line 752:		Line 733:
	== DLTA ==		== DLTA ==

	For an Anim Brush with 10 frames, there will be an initial frame		For an Anim Brush with 10 frames, there will be an initial frame followed by 10 Delta's (i.e ILBMS containing ANHD and DLTA
		⚫	chunks). Applying the first Delta to the initial frame generates the second frame, applying the second Delta to the second frame
	followed by 10 Delta's (i.e ILBMS containing ANHD and DLTA
	~~chunks)~~. Applying the ~~first~~ Delta to the ~~initial~~ frame ~~generates~~		generates the third frame, etc. Applying the last Delta thus brings back the first frame.
⚫	the second frame, applying the second Delta to the second frame
	generates the third frame, etc. Applying the last Delta thus
	brings back the first frame.

	The DLTA chunk begins with 16 LONG plane offets, of which DPaint		The DLTA chunk begins with 16 LONG plane offets, of which DPaint only uses the first 6 (at most). These plane offsets are either
		⚫	the offset (in bytes ) from the beginning of the DLTA chunk to the data for the corresponding plane, or Zero, if there was no
	only uses the first 6 (at most). These plane offsets are either
	~~the offset~~ (in ~~bytes~~ ) ~~from~~ the ~~beginning~~ of ~~the~~ ~~DLTA~~ ~~chunk~~ to		change in that plane. Thus the first plane offset is either 0 or 64.
⚫	the data for the corresponding plane, or Zero, if there was no
	change in that plane. Thus the first plane offset is either 0 or
	64.

	(The following description of the method is based on Gary Bonham's rewording of Jim Kent's RIFF documentation.)		(The following description of the method is based on Gary Bonham's rewording of Jim Kent's RIFF documentation.)
Line 770:		Line 745:
	Compression/decompression is performed on a plane-by-plane basis.		Compression/decompression is performed on a plane-by-plane basis.

	Each byte-column of the ~~bitplane~~ is compressed separately. A		Each byte-column of the bit plane is compressed separately. A 320x200 bit plane would have 40 columns of 200 bytes each. In
		⚫	general, the bit planes are always an even number of bytes wide, so for instance a 17x20 bit plane would have 4 columns of 20
	320x200 bitplane would have 40 columns of 200 bytes each. In
⚫	general, the ~~bitplanes~~ are always an even number of bytes wide,
	so for instance a 17x20 bitplane would have 4 columns of 20
	bytes each.		bytes each.

	Each column starts with an op-count followed by a number of		Each column starts with an op-count followed by a number of ops. If the op-count is zero, that's OK, it just means there's no change in this column from the last frame. The ops are of three kinds, and followed by a varying amount of data depending on which kind:
	ops. If the op-count is zero, that's ok, it just means there's
	no change in this column from the last frame. The ops are of
	three kinds, and followed by a varying amount of data depending
	on which kind:

	# SKIP - this is a byte with the hi bit clear that says how many rows to move the "dest" pointer forward, ie to skip. It is non-zero.		# SKIP - this is a byte with the hi bit clear that says how many rows to move the "dest" pointer forward, i.e. to skip. It is non-zero.
	# DUMP - this is a byte with the hi bit set. The hi bit is masked off and the remainder is a count of the number of bytes of data to XOR directly. It is followed by the bytes to copy.		# DUMP - this is a byte with the hi bit set. The hi bit is masked off and the remainder is a count of the number of bytes of data to XOR directly. It is followed by the bytes to copy.
	# RUN - this is a 0 byte followed by a count byte, followed by a byte value to repeat "count" times, XOR'ing it into the destination.		# RUN - this is a 0 byte followed by a count byte, followed by a byte value to repeat "count" times, XOR'ing it into the destination.

Steven Solie: /* ANIM.op8 */

2013-07-08T21:57:53Z

ANIM.op8

← Older revision		Revision as of 21:57, 8 July 2013
Line 545:		Line 545:
	Joe Porkka 10-jan-92		Joe Porkka 10-jan-92

	Anim method 8 is designed for maximum playback speed and acceptable		Anim method 8 is designed for maximum playback speed and acceptable packing rates (packing usually not as good as method 5, but more efficient than methods 1 -- 4). In addition, it is easier to convert existing Anim5 code to support Anim8 than Anim7.
	packing rates (packing usually not as good as method 5, but more
	efficient than methodes 1 -- 4). In addition, it is easier to convert
	existing Anim5 code to support Anim8 than Anim7.

	== Chunk Sequence ==		== Chunk Sequence ==

	Method 8 Anims should use the same Chunk Sequence as methods 1..5.		Method 8 Anims should use the same Chunk Sequence as methods 1..5. Alternatively the first frame may have a DLTA chunk instead of the BODY chunk.
	Alternativley the first frame may have a DLTA chunk instead
	of the BODY chunk.

	In that case the DLTA is the difference to a 'black frame'.		In that case the DLTA is the difference to a 'black frame'. A player has to clear all bit planes of the first bitmap to zero, and then call his DLTA unpack routines for this frame. The same rules about copying the first frame into both frame buffers still applies in this case.
	A player has to clear all bitplanes of the first bitmap to zero,
	and then call his DLTA unpack routines for this frame.
	The same rules about copying the first frame into both frame
	buffers still applies in this case.

	FORM ANIM		FORM ANIM
Line 578:		Line 569:
	...		...

			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). If desired, an ANHD chunk can appear here to provide timing data for the first frame. If it is here, the operation field should be =0.
	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). If desired, an ANHD
	chunk can appear here to provide timing data for the first
	frame. If it is here, the operation field should be =0.

	If the initial FORM ILBM uses a DLTA chunk, the ANHD chunk		If the initial FORM ILBM uses a DLTA chunk, the ANHD chunk must appear, and the operation field must be set to the
	must appear, and the operation field must be set to the
	according anim method.		according anim method.

	Each of the frames from frame 2 on up may use an anhd->operation		Each of the frames from frame 2 on up may use an anhd->operation of 0, 5 or 8. Note that only for the first frame in the file do you copy the image data into two buffers, not every time you get an ANHD->operation==0.
	of 0, 5 or 8. Note that only for the first frame in the file do
	you copy the image data into two buffers, not every time you get
	an ANHD->operation==0.

	== Chunk Formats ==		== Chunk Formats ==
Line 608:		Line 590:
	UBYTE interleave = 0 (see ANHD description above)		UBYTE interleave = 0 (see ANHD description above)
	UBYTE pad0 unused		UBYTE pad0 unused
	ULONG bits 32 option bits used by ~~methode~~=4 and 5.		ULONG bits 32 option bits used by method=4 and 5.
	~~methode~~ 8 uses only bit #0		method 8 uses only bit #0
	bit # set =0 set =1		bit # set =0 set =1
	=============================================		=============================================
Line 620:		Line 602:
	* 16 pointers same as in method 5		* 16 pointers same as in method 5

	In this method the DLTA Chunk begins with 16 pointers.		In this method the DLTA Chunk begins with 16 pointers. The first 8 longwords are pointers to the opcode lists for up to 8
	The ~~first~~ 8 longwords are ~~pointers~~ to ~~the~~ ~~opcode~~ ~~lists~~ ~~for~~ up to 8		planes. The second set of 8 longwords are unused. If there are less than 8 Planes all unused pointers are set to zero.
	planes. The second set of 8 longwords are unused. If there are
	less than 8 Planes all unused pointers are set to zero.

	Compression/decompression is performed on a plane-by-plane basis.		Compression/decompression is performed on a plane-by-plane basis. The following description of the method is similar to Jim Kent's methode 5, except that data is either in WORDs or LONGS, depending on bit 0 of the ANHD bits.
	The following description of the method is similar to
	Jim Kent's methode 5, except that data is either in WORDs or LONGS,
	depending on bit 0 of the ANHD bits.

			In method 8 the bit plane is split into vertical columns. Each column of the bit plane is compressed separately. A 320x200 bit plane would have 20 columns of 200 short data each (or 10 columns of 200 long data).
	In methode 8 the bitplane is split into vertical columns.
	Each column of the bitplane is compressed separately.
	A 320x200 bitplane would have 20 columns of 200 short datas each.
	(or 10 columns of 200 long datas)

			Each column of the bit plane is compressed separately. A 320x200 bit plane would have 20 (WORD) or 10 (LONG)columns of 200 bytes each. Each column starts with an op-count followed by a number of ops. If the op-count is zero, that's OK, it just means there's no change in this column from the last frame. The ops are of three classes, and followed by a varying amount of data depending on which class:
	Each column of the bitplane is compressed
	separately. A 320x200 bitplane would have 20
	(WORD) or 10 (LONG)columns of 200 bytes each.
	Each column starts with an op-count followed by a
	number of ops. If the op-count is zero, that's
	ok, it just means there's no change in this
	column from the last frame. The ops are of three
	classes, and followed by a varying amount of data
	depending on which class:

	# Skip ops - this is a word or long with the hi bit clear that says how many rows to move the "dest" pointer forward, ie to skip. It is non-zero. Note that the range of values is much larger for word and long data, 0x7fff and 0x7fffffff.		# Skip ops - this is a word or long with the hi bit clear that says how many rows to move the "dest" pointer forward, i.e. to skip. It is non-zero. Note that the range of values is much larger for word and long data, 0x7fff and 0x7fffffff.
	# Uniq ops - this is a word or long with the hi bit set. The hi bit is masked down and the remainder is a count of the number of bytes of data to copy literally. It's of course followed by the data to copy. Note that the range of values is much larger for word and long data, 0x7fff and 0x7fffffff.		# Uniq ops - this is a word or long with the hi bit set. The hi bit is masked down and the remainder is a count of the number of bytes of data to copy literally. It's of course followed by the data to copy. Note that the range of values is much larger for word and long data, 0x7fff and 0x7fffffff.
	# Same ops - this is a 0 word or long followed by a count word or long, followed by a word or long value to repeat count times. Note that the range of values is much larger for word and long data, 0xffff and 0xffffffff.		# Same ops - this is a 0 word or long followed by a count word or long, followed by a word or long value to repeat count times. Note that the range of values is much larger for word and long data, 0xffff and 0xffffffff.
Line 651:		Line 617:
	{{Note\|text=Do bear in mind that the data is compressed vertically rather than horizontally, so to get to the next word or long in the destination we add the number of bytes per row instead of one!}}		{{Note\|text=Do bear in mind that the data is compressed vertically rather than horizontally, so to get to the next word or long in the destination we add the number of bytes per row instead of one!}}

			There is a slight complication in the case of long data. Normally an Amiga BitMap is and even number of 16bit WORDs wide, so it is possible to have an image which is not an even number or LONGs wide. For example, an image which is 336 pixels wide is 42 bytes wide, 21 words wide, and 10.5 longs wide. In the case that the data is not an even number of longs wide, and the data is to be long compressed, then the last column of data is to be word compressed instead. So, that 336 pixel wide image would be compress as 10 long columns and 1 word column.
	There is a slight complication in the case of long data. Normally an
	Amiga BitMap is and even number of 16bit WORDs wide, so it is possible
	to have an image which is not an even number or LONGs wide. For example,
	an image which is 336 pixels wide is 42 bytes wide, 21 words wide, and
	10.5 longs wide. In the case that the data is not an even number of longs
	wide, and the data is to be long compressed, then the last column of
	data is to be word compressed instead. So, that 336 pixel wide image would
	be compress as 10 long columns and 1 word column.

	= ANIM.brush =		= ANIM.brush =

Steven Solie: /* ANIM.op7 */

2013-07-08T21:54:55Z

ANIM.op7

← Older revision		Revision as of 21:54, 8 July 2013
Line 460:		Line 460:
	: Wr. Neustaedterstr. 140		: Wr. Neustaedterstr. 140

	Anim method 7 is designed for maximum playback speed and acceptable		Anim method 7 is designed for maximum playback speed and acceptable packing rates (packing usually not as good as method 5, but more efficient than methods 1 -- 4)
	packing rates (packing usually not as good as method 5, but more
	efficient than methodes 1 -- 4)

	Method 7 was not originally in the IFF specification		Method 7 was not originally in the IFF specification but supported by the Public Domain Programs AAP/AAC.
	but supported by the Public Domain Programs AAP/AAC.

	== Chunk Sequence ==		== Chunk Sequence ==

	Method 7 Anims should use the same Chunk Sequence as methods 1..5.		Method 7 Anims should use the same Chunk Sequence as methods 1..5. Alternatively the first frame may have a DLTA chunk instead of the BODY chunk.
	Alternativley the first frame may have a DLTA chunk instead
	of the BODY chunk.

	In that case the DLTA is the difference to a 'black frame'.		In that case the DLTA is the difference to a 'black frame'. A player has to clear all bit planes of the first bitmap to zero, and then call his DLTA unpack routines for this frame.
	A player has to clear all bitplanes of the first bitmap to zero,
	and then call his DLTA unpack routines for this frame.

	FORM ANIM		FORM ANIM
Line 531:		Line 524:
	In this method the DLTA Chunk begins with 16 pointers. The first 8 longwords are pointers to the opcode lists for up to 8 planes. The second set of 8 longwords are pointers to the corresponding data lists. If there are less than 8 Planes all unused pointers are set to zero.		In this method the DLTA Chunk begins with 16 pointers. The first 8 longwords are pointers to the opcode lists for up to 8 planes. The second set of 8 longwords are pointers to the corresponding data lists. If there are less than 8 Planes all unused pointers are set to zero.

	Compression/decompression is performed on a plane-by-plane basis.		Compression/decompression is performed on a plane-by-plane basis. The following description of the method is similar to
			Jim Kent's method 5, except that data is stored in a separated data list (long or short, depending on bit#0 of the ANHD bits) and doesn't follow immediate after the opcode.
	The following description of the method is similar to
	Jim Kent's method 5, except that data is stored in a seperated
	datalist (long or short, depending on bit#0 of the ANHD bits)
	and doesn't follow immediate after the opcode.

			In method 7 the bit plane is split into vertical columns. Each column of the bit plane is compressed separately. A 320x200 bitplane would have 20 columns of 200 short datas each. (or 10 columns of 200 long datas)
	In method 7 the bitplane is splitted into vertical columns.
	Each column of the bitplane is compressed separately.
	A 320x200 bitplane would have 20 columns of 200 short datas each.
	(or 10 columns of 200 long datas)

	Each column starts with an op-count followed by a number		Each column starts with an op-count followed by a number of ops. If the op-count is zero, that's OK, it just means
		⚫	there's no change in this column from the last frame. The ops are of three classes. The ops refer to a varying
	of ops. If the op-count is zero, that's ok, it just means
		⚫	amount of data (to fetch from the corresponding data list) depending on which class:
	there's no change in this column from the last frame.
⚫	The ops are of three classes. The ops refer to a varying
⚫	amount of data (to fetch from the corresponding ~~datalist~~)
	depending on which class:

	# Skip ops - this is a byte with the hi bit clear that says how many rows to move the "dest" pointer forward, ie to skip. It is non-zero. Skip ops have no corresponding data-items in the ~~datalist~~.		# Skip ops - this is a byte with the hi bit clear that says how many rows to move the "dest" pointer forward, i.e. to skip. It is non-zero. Skip ops have no corresponding data-items in the data list.
	# Uniq ops - this is a byte with the hi bit set. The hi bit is masked down and the remainder is a count of the number of data to copy literally from the ~~datalist~~ to the "dest" pointer column. (Each data item to the next destination row) Data items may be long or short organized.		# Uniq ops - this is a byte with the hi bit set. The hi bit is masked down and the remainder is a count of the number of data to copy literally from the data list to the "dest" pointer column. (Each data item to the next destination row) Data items may be long or short organized.
	# Same ops - this is a 0 byte followed by a count byte. The count byte says how many rows of the current column are to be set to the same data-item. the data-item (long or short) is fetched from the ~~datalist~~.		# Same ops - this is a 0 byte followed by a count byte. The count byte says how many rows of the current column are to be set to the same data-item. the data-item (long or short) is fetched from the data list.

	{{Note\|text=Do bear in mind that the data is compressed vertically rather than horizontally, so to get to the next address in the destination we have to add the number of bytes per row instead of 2 (or 4)!}}		{{Note\|text=Do bear in mind that the data is compressed vertically rather than horizontally, so to get to the next address in the destination we have to add the number of bytes per row instead of 2 (or 4)!}}

Steven Solie at 21:52, 8 July 2013

2013-07-08T21:52:05Z

Show changes

Steven Solie: /* ANHD */

2013-07-08T21:45:05Z

ANHD

← Older revision		Revision as of 21:45, 8 July 2013
Line 946:		Line 946:

	{{Note\|text=The "bits" field was actually intended ( by the original creator of the ANIM format, Gary Bonham of SPARTA, Inc.) for use with only with compression method 4. I am using bit 2 of the bits field to indicate the Exclusive OR operation in the context of method 5, which seems like a reasonable generalization.}}		{{Note\|text=The "bits" field was actually intended ( by the original creator of the ANIM format, Gary Bonham of SPARTA, Inc.) for use with only with compression method 4. I am using bit 2 of the bits field to indicate the Exclusive OR operation in the context of method 5, which seems like a reasonable generalization.}}

			== DLTA ==

	For an Anim Brush with 10 frames, there will be an initial frame		For an Anim Brush with 10 frames, there will be an initial frame

Steven Solie: /* ANIM.brush */

2013-07-08T21:43:54Z

ANIM.brush

Show changes

Steven Solie: /* ANIM.op8 */

2013-07-08T18:56:39Z

ANIM.op8

Show changes

Steven Solie: /* Appendix for Anim7 Formats */

2013-07-08T18:48:32Z

Appendix for Anim7 Formats

← Older revision		Revision as of 18:48, 8 July 2013
Line 593:		Line 593:
	= ANIM.op7 =		= ANIM.op7 =

	= Appendix for Anim7 Formats =		== Appendix for Anim7 Formats ==

	Anim7 (July 92) by:		Anim7 (July 92) by:

Steven Solie: /* Supporting Software */

2013-07-08T18:48:07Z

Supporting Software

← Older revision		Revision as of 18:48, 8 July 2013
Line 586:		Line 586:
	== Supporting Software ==		== Supporting Software ==

	3-D Professional 1.0+ (Progressive Peripherals and Software)		* 3-D Professional 1.0+ (Progressive Peripherals and Software)
	View 1.7 and above (Public Domain) on a Fred Fish Disk		* View 1.7 and above (Public Domain) on a Fred Fish Disk
	MSA: Make Stereo ANIM (internal) Available upon request.		* MSA: Make Stereo ANIM (internal) Available upon request.
	PSA: Play Stereo ANIM (internal) Available upon request.		* PSA: Play Stereo ANIM (internal) Available upon request.

	= ANIM.op7 =		= ANIM.op7 =