SGA - Revision history

Paul Jensen: /* Decoders/Converters */

2014-09-23T14:41:45Z

Decoders/Converters

← Older revision		Revision as of 07:41, 23 September 2014
Line 311:		Line 311:

	== Decoders/Converters ==		== Decoders/Converters ==
	* A decoder has been written that can currently decode SGA files from Night Trap (SCD and 32X), Sewer Shark (including stream selection), Corpse Killer (SCD and 32X), Prize Fighter, Double Switch, as well as various other games, and convert them to AVI format files. It ~~has yet to be released to the public~~.		* A decoder called SCAT (SGA Conversion and Analysis Tool) has been written that can currently decode SGA files from Night Trap (SCD and 32X), Sewer Shark (including stream selection), Corpse Killer (SCD and 32X), Prize Fighter, Double Switch, as well as various other games, and convert them to AVI format files. It is available for download at SourceForge ([http://sourceforge.net/projects/sgaconversionandanalysistool/]).

	[[Category:Game Formats]]		[[Category:Game Formats]]
	[[Category:Platform-Dependent Codecs]]		[[Category:Platform-Dependent Codecs]]

Paul Jensen: /* Compressed Overlay Video $D4 */

2014-09-21T09:34:08Z

Compressed Overlay Video $D4

← Older revision		Revision as of 02:34, 21 September 2014
Line 244:		Line 244:
	The first frame of each animation contains a single palette in the usual format, but instead of following the tile data (as in other chunk types such as C1), the palette immediately precedes it. Tile data is LZSS compressed in the same way as C6 chunks, except that the copy count is represented by the top four bits of the block header, and the offset is represented by the remaining bits + 1.		The first frame of each animation contains a single palette in the usual format, but instead of following the tile data (as in other chunk types such as C1), the palette immediately precedes it. Tile data is LZSS compressed in the same way as C6 chunks, except that the copy count is represented by the top four bits of the block header, and the offset is represented by the remaining bits + 1.

	Tiles are stored in an unusual order. For example, the figure below shows the difference between the stored order and the layout order of the first two rows of tiles in a frame that is six tiles wide~~. Tiles are laid out in a zig-zag pattern, two lines at a time~~.		Tiles are stored in an unusual order. For example, the figure below shows the difference between the stored order and the layout order of the first two rows of tiles in a frame that is six tiles wide.

	<pre>		<pre>

Paul Jensen: /* Compressed Overlay Video $D4 */

2014-09-21T09:32:36Z

Compressed Overlay Video $D4

← Older revision		Revision as of 02:32, 21 September 2014
Line 244:		Line 244:
	The first frame of each animation contains a single palette in the usual format, but instead of following the tile data (as in other chunk types such as C1), the palette immediately precedes it. Tile data is LZSS compressed in the same way as C6 chunks, except that the copy count is represented by the top four bits of the block header, and the offset is represented by the remaining bits + 1.		The first frame of each animation contains a single palette in the usual format, but instead of following the tile data (as in other chunk types such as C1), the palette immediately precedes it. Tile data is LZSS compressed in the same way as C6 chunks, except that the copy count is represented by the top four bits of the block header, and the offset is represented by the remaining bits + 1.

	Tiles are stored in an unusual order. For example, the figure ~~above~~ shows the first two rows of tiles in a frame that is six tiles wide. Tiles are laid out in a zig-zag pattern, two lines at a time.		Tiles are stored in an unusual order. For example, the figure below shows the difference between the stored order and the layout order of the first two rows of tiles in a frame that is six tiles wide. Tiles are laid out in a zig-zag pattern, two lines at a time.

	<pre>		<pre>

Paul Jensen: /* Compressed Overlay Video $D4 */

2014-09-21T09:31:49Z

Compressed Overlay Video $D4

← Older revision		Revision as of 02:31, 21 September 2014
Line 240:		Line 240:

	== Compressed Overlay Video $D4 ==		== Compressed Overlay Video $D4 ==
	Chunks of this type are used in Corpse Killer (both versions) for storing animated sprites (flying zombies, etc). Files containing these chunks usually contain multiple animations. These chunks contain four extra bytes of metadata~~: two 8-bit values that each seem to indicate~~ a pixel offset, and a 16-bit value that appears to be an ID for the animation. ~~The first frame of each animation contains a single palette~~ in ~~the usual format, but instead of following the tile data~~, ~~the palette immediately precedes it. Tile data is LZSS compressed in the same way as other compressed~~ frames~~, except note~~ that ~~the copy count~~ is ~~represented by the top four bits~~ of ~~the block header, and the offset is represented by the remaining bits + 1~~.		Chunks of this type are used in Corpse Killer (both versions) for storing animated sprites (flying zombies, etc). Files containing these chunks usually contain multiple animations. These chunks contain four extra bytes of metadata. The first byte indicates a horizontal pixel offset, and the next byte is a vertical pixel offset. The next two bytes are a 16-bit value that appears to be an ID for the animation. Due to the unusual way in which tiles are laid out, frames always have a width and height that is a multiple of two.

	Tiles are stored in an unusual order, ~~as shown in~~ the figure ~~below:~~		The first frame of each animation contains a single palette in the usual format, but instead of following the tile data (as in other chunk types such as C1), the palette immediately precedes it. Tile data is LZSS compressed in the same way as C6 chunks, except that the copy count is represented by the top four bits of the block header, and the offset is represented by the remaining bits + 1.

			Tiles are stored in an unusual order. For example, the figure above shows the first two rows of tiles in a frame that is six tiles wide. Tiles are laid out in a zig-zag pattern, two lines at a time.

	<pre>		<pre>
Line 256:		Line 258:
	</pre>		</pre>

	~~The figure above shows two rows of six tile indexes. Tiles are laid out on the screen in a zig-zag pattern, two lines at a time.~~ Tiles can be laid out using the following algorithm:		Tiles can be laid out using the following algorithm. Note that the backwards slash symbol ("\") means integer division, which is equivalent to the Floor function found in C and other programming languages.

	<pre>		<pre>

Paul Jensen: /* Chunk Types */

2014-09-11T16:11:45Z

Chunk Types

Paul Jensen: /* Compressed Overlay Video $D4 */

2014-09-11T15:15:59Z

Compressed Overlay Video $D4

← Older revision		Revision as of 08:15, 11 September 2014
Line 256:		Line 256:
	</pre>		</pre>

	The figure above shows two rows of six tile indexes. Tiles are laid out on the screen in a zig-zag pattern, two lines at a time.		The figure above shows two rows of six tile indexes. Tiles are laid out on the screen in a zig-zag pattern, two lines at a time. Tiles can be laid out using the following algorithm:

			<pre>
			For row = 0 To heightInTiles - 1
			For col = 0 To widthInTiles - 1
			pos.X = ((col * 2) Mod widthInTiles) + (row Mod 2)
			pos.Y = ((row \ 2) * 2) + (col \ (widthInTiles \ 2))
			rearrangedTileIndex(col, row) = originalTileIndex(pos.X, pos.Y)
			Next
			Next
			</pre>

	== Compressed Video $E8, $E9 ==		== Compressed Video $E8, $E9 ==

Paul Jensen: /* Compressed Overlay Video $D4 */

2014-09-11T10:49:58Z

Compressed Overlay Video $D4

@@ Line 240: / Line 240: @@
 == Compressed Overlay Video $D4 ==
-Chunks of this type are used in Corpse Killer (both versions) for storing animated sprites (flying zombies, etc). Files containing these chunks usually contain multiple animations. These chunks contain four extra bytes of metadata: two 8-bit values that each seem to indicate a pixel offset, and a 16-bit value that appears to be an ID for the animation. The first frame of each animation contains a palette in the usual format, but instead of following the frame data, the palette immediately precedes the frame data. Frame data is LZSS compressed in the same way as other compressed frames, except note that the copy count is represented by the top four bits of the block header, and the offset is the remaining bits + 1.
+Chunks of this type are used in Corpse Killer (both versions) for storing animated sprites (flying zombies, etc). Files containing these chunks usually contain multiple animations. These chunks contain four extra bytes of metadata: two 8-bit values that each seem to indicate a pixel offset, and a 16-bit value that appears to be an ID for the animation. The first frame of each animation contains a single palette in the usual format, but instead of following the tile data, the palette immediately precedes it. Tile data is LZSS compressed in the same way as other compressed frames, except note that the copy count is represented by the top four bits of the block header, and the offset is represented by the remaining bits + 1.
 == Compressed Video $E8, $E9 ==

Paul Jensen at 10:10, 11 September 2014

2014-09-11T10:10:42Z

← Older revision		Revision as of 03:10, 11 September 2014
Line 238:		Line 238:

	Palette maps in chunks of this type use a single bit to indicate the palette of each tile, since in the case of Sewer Shark, most of the video seen during gameplay uses only two palettes, and so the palette map only needs one bit for each entry (0 = palette #1, and 1 = palette #2).		Palette maps in chunks of this type use a single bit to indicate the palette of each tile, since in the case of Sewer Shark, most of the video seen during gameplay uses only two palettes, and so the palette map only needs one bit for each entry (0 = palette #1, and 1 = palette #2).

			== Compressed Overlay Video $D4 ==
			Chunks of this type are used in Corpse Killer (both versions) for storing animated sprites (flying zombies, etc). Files containing these chunks usually contain multiple animations. These chunks contain four extra bytes of metadata: two 8-bit values that each seem to indicate a pixel offset, and a 16-bit value that appears to be an ID for the animation. The first frame of each animation contains a palette in the usual format, but instead of following the frame data, the palette immediately precedes the frame data. Frame data is LZSS compressed in the same way as other compressed frames, except note that the copy count is represented by the top four bits of the block header, and the offset is the remaining bits + 1.

	== Compressed Video $E8, $E9 ==		== Compressed Video $E8, $E9 ==

Paul Jensen: /* Compressed Video $C2 */

2014-09-07T05:48:22Z

Compressed Video $C2

← Older revision		Revision as of 22:48, 6 September 2014
Line 183:		Line 183:
	Note that compressed tile map entries do not contain a tile index. The tile index can be determined by adding up the number of compressed tiles so far encountered in the tile map, as frames that use compressed tile maps store their tiles in order.		Note that compressed tile map entries do not contain a tile index. The tile index can be determined by adding up the number of compressed tiles so far encountered in the tile map, as frames that use compressed tile maps store their tiles in order.

	== Compressed Video $C2 ==		== Compressed Video $C2, $C4 ==
	Not much is currently known about ~~this type~~ of chunk except that ~~it contains~~ four additional bytes of metadata, and in contrast to other chunk types, palette data immediately follows the metadata instead of following the tile data. The four additional bytes of metadata contain two 16-bit values that indicate the lengths of two blocks of data contained within the chunk. The first block of data contains codes used for ~~reassembling~~ the ~~compressed~~ tile data ~~contained~~ in the second block. Compression seems to be based on nibbles rather than bytes, which is appropriate for Mega Drive graphics since one 4-bit nibble represents one pixel on the screen. The exact compression scheme is unknown at this time. A third block of data (whose length can be derived from the length of the chunk minus the lengths of the first and second data blocks) ~~sometimes follows~~ the second block~~. Its purpose is also currently unknown~~.		Not much is currently known about these types of chunk except that they contain four additional bytes of metadata, and in contrast to other chunk types, palette data immediately follows the metadata instead of following the tile data. The four additional bytes of metadata contain two 16-bit values that indicate the lengths of two blocks of data contained within the chunk. The first block of data contains LZSS-like compression codes used for decompressing the tile data in the second block. An additional block of compressed data (whose length can be derived from the length of the chunk minus the lengths of the first and second data blocks) may follow the second block depending on the total size of the compressed data.

	== Compressed Video $C6, $C7, $C8 ==		== Compressed Video $C6, $C7, $C8 ==

Paul Jensen: Added information about compressed tile maps

2014-09-05T16:55:24Z

Added information about compressed tile maps

@@ Line 153: / Line 153: @@
 When drawing a tile you would select the palette based upon PalMap. Note that palette maps for 2 palette frames use only 1 bit per palette map entry vs 2 bits for 3 or 4 palettes.
-If a frame has a tilemap, the tilemap immediately follows the palette data. Each tilemap entry is 16 bits long, and so the length of the tilemap in bytes is tilesPerColumn * tilesPerRow * 2. Tilemaps also contain palette information, and so frames with tilemaps do not contain a separate palette map. The top 4 bits of a tilemap entry indicate the palette index of the tile, and the remaining 12 bits indicate the index of the tile itself.
+If a frame has a tile map, the tile map immediately follows the palette data. Each entry in a raw tile map is 16 bits long, and so the length of the tilemap in bytes is tilesPerColumn * tilesPerRow * 2. Tile maps also contain palette maps, so frames with tile maps do not contain a separate palette map. Below is the structure of a tile map entry:
 == Compressed Video $C2 ==

← Older revision		Revision as of 09:11, 11 September 2014
Line 87:		Line 87:
	* $C1: uncompressed video (used in Night Trap SCD, Sewer Shark, Corpse Killer SCD, and others)		* $C1: uncompressed video (used in Night Trap SCD, Sewer Shark, Corpse Killer SCD, and others)
	* $C2: compressed video (used in Corpse Killer SCD, Slam City with Scottie Pippen, and others?)		* $C2: compressed video (used in Corpse Killer SCD, Slam City with Scottie Pippen, and others?)
	* $C4: compressed? video (used in Slam City with Scottie Pippen)		* $C4: compressed video (used in Slam City with Scottie Pippen)
	* $C6: compressed video (used in Night Trap SCD "DPLOGO.SGA", Sewer Shark, Make My Video C&C, and others)		* $C6: compressed video (used in Night Trap SCD "DPLOGO.SGA", Sewer Shark, Make My Video C&C, and others)
	* $C7: compressed video (used in Prize Fighter and others)		* $C7: compressed video (used in Prize Fighter and others)
Line 94:		Line 94:
	* $CD: compressed video (used in Double Switch)		* $CD: compressed video (used in Double Switch)
	* $D1: uncompressed overlay video (used in Sewer Shark when killing a Ratigator(TM), etc)		* $D1: uncompressed overlay video (used in Sewer Shark when killing a Ratigator(TM), etc)
	* $D4: compressed? overlay video (used in Corpse Killer SCD/32X for the zombies)		* $D4: compressed overlay video (used in Corpse Killer SCD/32X for the zombies)
	* $E7: (un)compressed video (used in the Make My Video series)		* $E7: (un)compressed video (used in the Make My Video series)
	* $E8: compressed video keyframe (used in Ground Zero Texas)		* $E8: compressed video keyframe (used in Ground Zero Texas)
	* $E9: compressed video interframe (used in Ground Zero Texas)		* $E9: compressed video interframe (used in Ground Zero Texas)
	* $F0: container for other chunks (used in Slam City)		* $F0: container for other chunks (used in Slam City and other games)
	* $F1: container for other chunks (used in Slam City)		* $F1: container for other chunks (used in Slam City and other games)
	* $F2: metadata of unknown use		* $F2: metadata of unknown use

	As of this writing, the formats and/or compression schemes of the following types are generally understood: 81, A1, C1, C6, C7, C8, CB, CD, D1, E7, E8, E9, and F1.		As of this writing, the formats and/or compression schemes of the following types are generally understood: 81, A1, C1, C6, C7, C8, CB, CD, D1, D4, E7, E8, E9, and F1.

	== Encoded Video $81 ==		== Encoded Video $81 ==