BMV - Revision history

Kostya: /* Discworld 3 BMV */ fill information from ScummVM code

2021-07-20T12:55:07Z

Discworld 3 BMV: fill information from ScummVM code

← Older revision		Revision as of 05:55, 20 July 2021
Line 98:		Line 98:

	Frames stored in data chunk seems to have the same structure as v2, except that palette must not be present and audio is stored in fixed size per chunk <code>audio_max_size</code> or <code>audio_max_size - audio_blob_size</code> if flag <code>0x40</code> is set.		Frames stored in data chunk seems to have the same structure as v2, except that palette must not be present and audio is stored in fixed size per chunk <code>audio_max_size</code> or <code>audio_max_size - audio_blob_size</code> if flag <code>0x40</code> is set.

			=== Video ===

			As stated in ScummVM Tinsel engine source code [https://github.com/scummvm/scummvm/blob/master/engines/tinsel/bmv.cpp#L347]:

			Encoded frame can contain 3 operations:
			* delta - copy previously written N pixels, either from previous line, previous frame, or an offset within previous frame
			* raw - copy N values from source stream
			* run - repeat last pixel value N times

			Encoding is convoluted and relies on nibbles - lo nibble = 4 bottom bits of a byte, hi nibble = 4 upper bits of a byte.

			Operations keep rotating, after delta operation there can follow RAW or RUN operation, after RAW only RUN or DELTA and after RUN only DELTA or RAW can follow.

			Which operation will follow depends on lowest bit of a current nibble.

			Length of each operation can be encoded either directly or via special variable length encoding. From a nibble two bottom bits are preprended to final value, then next nibble is processed, if a new nibble is needed next byte is read from the stream. Process ends if any of two upper bits are set, in that case two upper bits are prepended as well.

			Which length is going to be used depends on an quite convoluted encoding and there are two ways how they are encoded (note that operations still keep switching).

			In outer loop, if:
			* hi nibble has any of 2 upper bits set then only byte is read in this iteration and if:
			** lo nibble has any of 2 upper bits set then length is between 7-30
			** lo nibble has none of 2 upper bits set then there are 2 operations encoded and each nibble represents value 1-6
			* hi nibble has none of 2 upper bits set then multiple bytes can be read in this iterations and if:
			** lo nibble has any of 2 upper bits set then length is 1-6
			** lo nibble has none of 2 upper bits set then length is using variable length encoding.
			*** if there hi nibble left then there is another operation with length 1-6
			** start of other encoding - inner loop

			In inner loop, if:
			* lo nibble has any of 2 upper bits set then length is between 7-30
			* lo nibble has none of 2 upper bits set then length is using variable length encoding
			* hi nibble has any of 2 upper bits set then length is between 1-6 and inner loop ends
			* hi nibble has none of 2 upper bits set then the rest used to select next operation and partly encode next length of next operation

			Frame image data is always written from left to right, from top to bottom.

	=== Audio ===		=== Audio ===

Kostya at 12:51, 20 July 2021

2021-07-20T12:51:17Z

← Older revision		Revision as of 05:51, 20 July 2021
Line 97:		Line 97:
	bytes 30-31 frame height		bytes 30-31 frame height

	Frames stored in data chunk seems to have the same structure as v2, except that palette must not be present and audio is stored in fixed size per chunk <code>audio_max_size<code> or <code>audio_max_size - audio_blob_size</code> if flag <code>0x40</code> is set.		Frames stored in data chunk seems to have the same structure as v2, except that palette must not be present and audio is stored in fixed size per chunk <code>audio_max_size</code> or <code>audio_max_size - audio_blob_size</code> if flag <code>0x40</code> is set.

	=== Audio ===		=== Audio ===

Kostya: /* Video */

2011-11-06T15:35:49Z

Video

← Older revision		Revision as of 08:35, 6 November 2011
Line 40:		Line 40:
	=== Video ===		=== Video ===

	Video is packed ~~like RLE~~.		Video packing is rather exotic: frame data may be decoded in forward or backward direction.
			In the latter case input data is read from the end to beginning and frame updated the same way (right to left, bottom to top).

			Video decoder cycles between three states corresponding to the decoding modes:
			# copy data from the given offset of the frame
			# copy pixel values from input
			# fill some segment with the left (or right for backwards decoding) neighbour value

			The length of segment is defined by code which is read before performing operation. The lowest bit of that code specifies whether the next mode should be skipped or not.

			Length code is coded in unusual way too: each nibble provide next bits of the code.
			If any of two upper bits of the nibble are set that means that code decoding is complete, otherwise only two low bits of the nibble are prepended to the code. Code nibbles are packed into bytes, so one byte can actually contain codes for current and next operation.

	=== Audio ===		=== Audio ===

Kostya: /* Audio */

2011-11-06T15:23:33Z

Audio

← Older revision		Revision as of 08:23, 6 November 2011
Line 54:		Line 54:
	mul2 = mult_table[t >> 4];		mul2 = mult_table[t >> 4];

	Audio is decoded by fetching byte, multiplying it by mul1 or mul2 (even samples - by mul1, odd samples - by mul2) and dividing by 32:		Audio is decoded by fetching byte, multiplying it by mul1 or mul2 (even samples - by mul1, odd samples - by mul2) and dividing by 32:

	int8_t *src;		int8_t *src;

Kostya: /* Discworld 3 BMV */

2011-11-06T15:22:55Z

Discworld 3 BMV

Show changes

Multimedia Mike: link to samples

2011-11-05T05:51:44Z

link to samples

← Older revision		Revision as of 22:51, 4 November 2011
Line 1:		Line 1:
	* Extensions: bmv		* Extensions: bmv
	* Company: Teeny Weeny Games		* Company: Teeny Weeny Games
			* Samples: http://samples.mplayerhq.hu/game-formats/bmv/

	BMV is the file extension for FMV used in Discworld 2 and Discworld 3 games, actual format differs for them.		BMV is the file extension for FMV used in Discworld 2 and Discworld 3 games, actual format differs for them.

Kostya: /* Container */

2009-03-01T13:08:57Z

Container

← Older revision		Revision as of 06:08, 1 March 2009
Line 84:		Line 84:
	bytes 28-29 frame width		bytes 28-29 frame width
	bytes 30-31 frame height		bytes 30-31 frame height

			Frames stored in data chunk seems to have the same structure as v2.

	[[Category:Audio Codecs]]		[[Category:Audio Codecs]]

Kostya at 12:37, 1 March 2009

2009-03-01T12:37:32Z

@@ Line 61: / Line 61: @@
      blobsize--;
+   }
 [[Category:Audio Codecs]]

Kostya: /* Audio */

2008-12-03T07:08:42Z

Audio

← Older revision		Revision as of 00:08, 3 December 2008
Line 46:		Line 46:
	Each blob contains a byte with multipliers and actual data. Two multipliers are stored in a single byte which is cyclically rotated left by one		Each blob contains a byte with multipliers and actual data. Two multipliers are stored in a single byte which is cyclically rotated left by one

	mult_table[16] = { 16512, 8256, 4128, 2064, 1032, 516, 258, 192~~, 217~~, 129, 88, 64, 56, 48, 40, 36, 32 }		mult_table[16] = { 16512, 8256, 4128, 2064, 1032, 516, 258, 192, 129, 88, 64, 56, 48, 40, 36, 32 }

	t = get_byte();		t = get_byte();

Kostya: /* Container format */

2008-12-03T07:07:23Z

Container format

← Older revision		Revision as of 00:07, 3 December 2008
Line 29:		Line 29:
	Data is stored in this order:		Data is stored in this order:

	audio (3675 bytes)		audio (3675 bytes for old audio block, 1 + blobs*65 for newer one)
	commands		commands
	palette (768 bytes)		palette (768 bytes)