Interplay Video - Revision history

Kostya: /* 16-Bit Data */

2009-12-14T20:30:27Z

16-Bit Data

← Older revision		Revision as of 13:30, 14 December 2009
Line 283:		Line 283:
	Format is mostly the same with these major changes:		Format is mostly the same with these major changes:
	* pixels are 15-bit stored as 16-bit little-endian words		* pixels are 15-bit stored as 16-bit little-endian words
			* data offset is 16, not 14. Those additional two bytes specify offset in the data for motion values for opcodes 0x2-0x4.
	* instead of comparing pair of pixel values, high bit is used (i.e. <code>P0 > P1 --> P0 & 0x8000</code>)		* instead of comparing pair of pixel values, high bit is used (i.e. <code>P0 > P1 --> P0 & 0x8000</code>)

Kostya: /* 16-Bit Data */ Someone has to do that...

2009-12-08T09:00:25Z

16-Bit Data: Someone has to do that...

@@ Line 279: / Line 279: @@
 == 16-Bit Data ==
-Later versions of the format support 16-bit RGB data. There are some differences between the 8- and 16-bit modes that are not yet documented.
+Later versions of the format support 16-bit RGB data. There are some differences between the 8- and 16-bit modes that are not yet documented (and unlikely to be in near future).
 [[Category:Video Codecs]]
 [[Category:Game Formats]]

Dashcloud: Update samples link

2006-08-17T22:15:19Z

Update samples link

← Older revision		Revision as of 15:15, 17 August 2006
Line 1:		Line 1:
	* Company: [[Interplay Entertainment]]		* Company: [[Interplay Entertainment]]
	* Samples: [http://~~www~~.mplayerhq.hu~~/MPlayer/samples~~/game-formats/interplay-mve/ http://~~www~~.mplayerhq.hu~~/MPlayer/samples~~/game-formats/interplay-mve/]		* Samples: [http://samples.mplayerhq.hu/game-formats/interplay-mve/ http://samples.mplayerhq.hu/game-formats/interplay-mve/]

	Interplay Video is encapsulated inside [[Interplay MVE]] files. It comes in both 8- and 16-bit flavors, tracking the evolution of PC graphics capabilities in the mid-late 1990s. The page only describes the 8-bit variation right now.		Interplay Video is encapsulated inside [[Interplay MVE]] files. It comes in both 8- and 16-bit flavors, tracking the evolution of PC graphics capabilities in the mid-late 1990s. The page only describes the 8-bit variation right now.

Multimedia Mike: sample link

2006-03-15T04:24:36Z

sample link

← Older revision		Revision as of 21:24, 14 March 2006
Line 1:		Line 1:
	* Company: [[Interplay Entertainment]]		* Company: [[Interplay Entertainment]]
			* Samples: [http://www.mplayerhq.hu/MPlayer/samples/game-formats/interplay-mve/ http://www.mplayerhq.hu/MPlayer/samples/game-formats/interplay-mve/]

	Interplay Video is encapsulated inside [[Interplay MVE]] files. It comes in both 8- and 16-bit flavors, tracking the evolution of PC graphics capabilities in the mid-late 1990s. The page only describes the 8-bit variation right now.		Interplay Video is encapsulated inside [[Interplay MVE]] files. It comes in both 8- and 16-bit flavors, tracking the evolution of PC graphics capabilities in the mid-late 1990s. The page only describes the 8-bit variation right now.

Multimedia Mike: note about frame accounting

2006-02-05T18:31:00Z

note about frame accounting

← Older revision		Revision as of 11:31, 5 February 2006
Line 269:		Line 269:
	P0 P1 P0 P1 P0 P1 P0 P1		P0 P1 P0 P1 P0 P1 P0 P1
	P1 P0 P1 P0 P1 P0 P1 P0		P1 P0 P1 P0 P1 P0 P1 P0

			== Frame Accounting ==

			The video coding method technically keeps track of 3 frames: The current frame, the last frame, and the second last frame (the frame from 2 frames ago). The video decoder will typically be implemented using 2 frames, one for current frame and one for last frame. When a new frame decode operation begins, the decoder actually begins drawing on the frame that was current 2 frames ago.

			Encoding modes 0x1 and 0x2 can be a little confusing without the above piece of knowledge. Mode 0x1 uses the block from the same position from the frame 2 frames ago. If the decoder is currently rendering on the frame created 2 frames ago, the block can safely be skipped in order to be unchanged. Similarly, mode 0x2 copies a block using a motion vector that will point right and down from the current block, but it copies "from the current frame". Due to the assumed double-buffering scheme, the data will actually come from the second last frame.

	== 16-Bit Data ==		== 16-Bit Data ==

Multimedia Mike: mention 16-bit data

2006-02-05T18:29:27Z

mention 16-bit data

← Older revision		Revision as of 11:29, 5 February 2006
Line 269:		Line 269:
	P0 P1 P0 P1 P0 P1 P0 P1		P0 P1 P0 P1 P0 P1 P0 P1
	P1 P0 P1 P0 P1 P0 P1 P0		P1 P0 P1 P0 P1 P0 P1 P0

			== 16-Bit Data ==

			Later versions of the format support 16-bit RGB data. There are some differences between the 8- and 16-bit modes that are not yet documented.

	[[Category:Video Codecs]]		[[Category:Video Codecs]]
	[[Category:Game Formats]]		[[Category:Game Formats]]

Multimedia Mike: /* Decoding Flow */

2006-02-05T18:26:57Z

Decoding Flow

← Older revision		Revision as of 11:26, 5 February 2006
Line 9:		Line 9:
	== Decoding Flow ==		== Decoding Flow ==

	First, the data is processed in 8x8 pixel blocks. There are 4 bits associated with each block giving the particular encoding to use for that block, giving a total of 16 possible encodings for a given block. These 4-bit pieces come from the most recent 0xf opcode data stream. ~~They all~~ appear to be used (or at least supported by the player). So, I'll go over the encodings for each of the 16 encoding types. The rendering process keeps track of the most recent frame in a separate buffer, and uses this double-buffering technique in the common way for animation. The current frame's data is used in the construction of the next frame. In the following description, "current frame" will refer to the most recently displayed frame, and "new frame" will refer to the frame currently being constructed for display. "map stream" will refer to the data grabbed from the 0xf Opcode data, and "data stream" will refer to the data grabbed from the 0x11 opcode data.		First, the data is processed in 8x8 pixel blocks. There are 4 bits associated with each block giving the particular encoding to use for that block, giving a total of 16 possible encodings for a given block. These 4-bit pieces come from decoding map defined by the most recent 0xf opcode in the [[Interplay MVE]] data stream. All 16 possible opcodes appear to be used (or at least supported by the player). Note that every 8x8 block in the frame should be represented by a 4-bit nibble in the decoding map and that the decoding map should be a predictable size:

			((width * height)pixels/frame / (8 * 8)pixels/block) * (1/2)bytes/block = bytes/frame

			When decoding the block map, the bottom 4 bits (bits 3-0) are used first, then the top 4 bits.

			I'll go over the encodings for each of the 16 encoding types. The rendering process keeps track of the most recent frame in a separate buffer, and uses this double-buffering technique in the common way for animation. The current frame's data is used in the construction of the next frame. In the following description, "current frame" will refer to the most recently displayed frame, and "new frame" will refer to the frame currently being constructed for display. "map stream" will refer to the data grabbed from the 0xf Opcode data, and "data stream" will refer to the data grabbed from the 0x11 opcode data.

	== Encoding 0x0 ==		== Encoding 0x0 ==

Multimedia Mike: oops, wrong convention

2006-02-05T18:17:32Z

oops, wrong convention

← Older revision		Revision as of 11:17, 5 February 2006
Line 243:		Line 243:
	Now, in this case, if P4 <= P5, [P0 P1 P2 P3 B0 B1 B2 B3 B4 B5 B6 B7] represent the left half of the block and the other bytes represent the right half. If P4 > P5, then [P0 P1 P2 P3 B0 B1 B2 B3 B4 B5 B6 B7] represent the top half of the block and the other bytes represent the bottom half.		Now, in this case, if P4 <= P5, [P0 P1 P2 P3 B0 B1 B2 B3 B4 B5 B6 B7] represent the left half of the block and the other bytes represent the right half. If P4 > P5, then [P0 P1 P2 P3 B0 B1 B2 B3 B4 B5 B6 B7] represent the top half of the block and the other bytes represent the bottom half.

	== Encoding 0xb~~: 64-Color Block~~ ==		== Encoding 0xb ==
	In this encoding we get raw pixel data in the data stream -- 64 bytes of pixel data. 1 byte for each pixel, and in the standard order (l->r, t->b).		In this encoding we get raw pixel data in the data stream -- 64 bytes of pixel data. 1 byte for each pixel, and in the standard order (l->r, t->b).

Multimedia Mike: /* Encoding 0xb */

2006-02-05T18:16:42Z

Encoding 0xb

← Older revision		Revision as of 11:16, 5 February 2006
Line 243:		Line 243:
	Now, in this case, if P4 <= P5, [P0 P1 P2 P3 B0 B1 B2 B3 B4 B5 B6 B7] represent the left half of the block and the other bytes represent the right half. If P4 > P5, then [P0 P1 P2 P3 B0 B1 B2 B3 B4 B5 B6 B7] represent the top half of the block and the other bytes represent the bottom half.		Now, in this case, if P4 <= P5, [P0 P1 P2 P3 B0 B1 B2 B3 B4 B5 B6 B7] represent the left half of the block and the other bytes represent the right half. If P4 > P5, then [P0 P1 P2 P3 B0 B1 B2 B3 B4 B5 B6 B7] represent the top half of the block and the other bytes represent the bottom half.

	== Encoding 0xb ==		== Encoding 0xb: 64-Color Block ==
	In this encoding we get raw pixel data in the data stream -- 64 bytes of pixel data. 1 byte for each pixel, and in the standard order (l->r, t->b).		In this encoding we get raw pixel data in the data stream -- 64 bytes of pixel data. 1 byte for each pixel, and in the standard order (l->r, t->b).

Multimedia Mike: add anonymous credit

2006-02-05T07:39:19Z

add anonymous credit

← Older revision		Revision as of 00:39, 5 February 2006
Line 2:		Line 2:

	Interplay Video is encapsulated inside [[Interplay MVE]] files. It comes in both 8- and 16-bit flavors, tracking the evolution of PC graphics capabilities in the mid-late 1990s. The page only describes the 8-bit variation right now.		Interplay Video is encapsulated inside [[Interplay MVE]] files. It comes in both 8- and 16-bit flavors, tracking the evolution of PC graphics capabilities in the mid-late 1990s. The page only describes the 8-bit variation right now.

			== Credits ==

			The technical description on this page is originally based on an anonymous and thorough description of the format published when Interplay was proactive about pursuing individuals who tried to understand their data format. "BG" refers to the PC game Baldur's Gate, the apparent focus of the author's analysis.

	== Decoding Flow ==		== Decoding Flow ==