https://wiki.multimedia.cx/api.php?action=feedcontributions&user=Renikrill&feedformat=atomMultimediaWiki - User contributions [en]2024-03-29T05:55:44ZUser contributionsMediaWiki 1.39.5https://wiki.multimedia.cx/index.php?title=Packed_Animation_File&diff=12228Packed Animation File2010-02-03T11:02:29Z<p>Renikrill: </p>
<hr />
<div>* Extension: paf<br />
* Company: Amazing Studio<br />
* Samples: http://samples.mplayerhq.hu/game-formats/hod-paf/ (hod1-partial.paf)<br />
<br />
A Packed Animation File (PAF) is a movie used in the Windows version of the game [http://www.mobygames.com/game/heart-of-darkness/ Heart Of Darkness]. The source code for a reverse engineered decoder is available at: http://cyxdown.free.fr/pafdec<br />
<br />
There is also a PlayStation version of this game; which employs the [[PlayStation Motion Decoder]] format for its FMV cutscenes, rather than this proprietary PAF format. <br />
<br />
== Archive Format ==<br />
The Windows version of Heart Of Darkness contains a large data file called hod.paf. This file contains 25 PAF files concatenated together and prepended with a header. The header is 100 bytes long and consists of 25 little endian, 32-bit numbers which are absolute offsets into the archive file. For example, bytes 0-3 contain the number 0x000000C8 = 100 which indicates that the first file occurs immediately following the 100-byte header.<br />
<br />
== File Format ==<br />
A PAF consists of a header and a series of interleaved audio and video data. The video data is stored with a custom paletted video encoding method. The audio is stored as uncompressed, stereo, 16-bit, little endian [[PCM]] data.<br />
<br />
All multi-byte numbers are stored in little endian format.<br />
<br />
bytes 0-55 signature<br />
bytes 56-127 unknown; might be unused bytes for the signature block<br />
bytes 132-135 frame count<br />
bytes 140-143 video width<br />
bytes 144-147 video height<br />
bytes 152-155 read buffer size<br />
bytes 156-159 number of frame blocks to preload<br />
bytes 160-163 frame blocks count<br />
bytes 164-167 starting offset of multimedia data<br />
bytes 168-171 max video frames block count<br />
bytes 172-175 max audio frames block count<br />
<br />
The 55-byte signature field should contain the string "Packed Animation File V1.0\n(c) 1992-96 Amazing Studio\x0A\x1A".<br />
<br />
''Several tables follow''<br />
<br />
'''INCOMPLETE'''<br />
<br />
== Video Codec ==<br />
The custom video codec is a paletted video codec that maintains an array of 256 3-byte values. Each value has a range of 6 bits (due to [[VGA]]-era graphics) which will probably need to be scaled to support the more common 8-bit RGB component model.<br />
<br />
The video resolution is usually 256x192. In fact, the reverse engineered decoder hardcodes these values as constants although they appear to be encoded in the file header.<br />
<br />
The video codec maintains a ring buffer of 4 frames that are all allocated and initialized to 0 at the beginning of the decode process. The codec may refer back to any of the other 3 frames while decoding the current video frame.<br />
<br />
allocate array of 4 video_frames and initialize to 0<br />
current_frame = 0<br />
loop:<br />
decode data to video_frames[current_frame]<br />
current_frame = current_frame + 1<br />
<br />
Decoding a video frame operates by processing the video frame as a sequence of opcodes and data:<br />
<br />
consume next byte as opcode<br />
if bit 5 of opcode is set (opcode & 0x20):<br />
frame is a keyframe<br />
clear all 4 video_frames to 0<br />
reset current_frame to 0<br />
if bit 6 of opcode is set (opcode * 0x40):<br />
frame begins with palette update<br />
consume next byte as index<br />
consume next byte as count<br />
starting at the palette entry denoted by index,<br />
copy (count * 3) bytes from bytestream to palette <br />
process the lower 4 bits of the opcode<br />
<br />
For the last step of the opcode decoding process, there are 4 valid encoding modes: 0, 1, 2, and 4.<br />
<br />
=== Mode 0 ===<br />
Block-based motion compensation using 4x4 blocks with either horizontal or vertical vectors; might incorporate VQ as well. <br />
<br />
'''INCOMPLETE'''<br />
<br />
=== Mode 1 ===<br />
Uncompressed data. This mode specifies that (width * height) bytes should be copied directly from the encoded buffer into the output. Note that there are 2 unknown bytes before the raw data (possibly chunk length data; this needs to be verified). Thus, a mode 1 chunk would be laid out as:<br />
<br />
<nowiki>0x01 [2 unknown bytes] [width * height bytes of video data]</nowiki><br />
<br />
=== Mode 2 ===<br />
Copy reference frame: Consume the next byte in the stream as the reference frame (which should be 0, 1, 2, or 3, and should not be the same as the current frame number). Copy the specified reference frame to the current frame.<br />
<br />
=== Mode 4 ===<br />
Run length encoding: <br />
<br />
skip the next 2 bytes in the bytestream (chunk length?)<br />
while there is still data in the bytestream, consume next byte as code<br />
if code < 0:<br />
consume next byte as run code<br />
count = -code + 1<br />
output count copies of run code<br />
else:<br />
count = code + 1<br />
copy count bytes from bytestream to output <br />
<br />
[[Category:Video Codecs]]<br />
[[Category:Game Formats]]</div>Renikrillhttps://wiki.multimedia.cx/index.php?title=CNM&diff=12126CNM2010-01-07T10:12:00Z<p>Renikrill: </p>
<hr />
<div>* Company: [[Arxel Tribe]]<br />
* Extension: cnm<br />
* Samples: [http://samples.mplayerhq.hu/game-formats/ring-cnm/ http://samples.mplayerhq.hu/game-formats/ring-cnm/]<br />
<br />
CNM is a multimedia format used in the computer game [http://www.mobygames.com/game/windows/ring-the-legend-of-the-nibelungen Ring: The Legend of the Nibelungen].<br />
<br />
[[Category:Game Formats]]</div>Renikrillhttps://wiki.multimedia.cx/index.php?title=PSMF&diff=12125PSMF2010-01-07T10:06:13Z<p>Renikrill: /* Header format */</p>
<hr />
<div>* Extensions: pmf<br />
* Company: [[Sony]]<br />
* Samples: http://samples.mplayerhq.hu/playstation/<br />
<br />
Short for PlayStation Portable Movie Format, PSMF is a SONY proprietary format used for movies intended to be played on the PSP portable game console. The format is based on [[MPEG]], and contains [[H.264]] video and [[Sony ATRAC]] audio.<br />
<br />
PSMF files start with a variable length header, followed by MPEG Program Stream data. The video data is carried in PES packets using a stream_id of 0xE0, and audio data is carried in private_stream_1 PES packets.<br />
<br />
== Header format ==<br />
'''Byte order: ''BIG endian'''''<br />
<br />
{| border="1"<br />
! Offset !! Name !! Bits !! Type !! Semantics<br />
|-<br />
| 0x0 || magic || 32 || ASCII || "PSMF"<br />
|-<br />
| 0x4 || version_num || 32 || ASCII || version number<br />
|-<br />
| 0x8 || data_offset || 32 || be int || PMF-relative data offset. - this is seemingly always 2048 bytes<br />
|-<br />
| 0xc || data_size || 32 || be int || total size of PMF data (subsequent-to 0x800 data-offset)<br />
|}<br />
<br />
The aforementioned 16-bytes delimits the total length of the PMF header; which is proceeded-with 64-bytes of null padding-data.<br />
Given this; the following block-address-map is invariably always situated at 0x50.<br />
<br />
{| border="1"<br />
! Offset !! Name !! Bits !! Type !! Semantics<br />
|-<br />
| 0x50 || table_size || 32 || be int || the overall length (from 0x54 -) of the mapping-table.<br />
|-<br />
| 0x54 || unknown || 16 || be int || always 0?<br />
|-<br />
| 0x56 || tick_freq || 32 || be int || ?<br />
|-<br />
| 0x5a || unknown || 16 || be int || always 0?<br />
|-<br />
| 0x5c || duration || 32 || be int || stream duration in ticks<br />
|-<br />
| 0x60 || mux_rate || 32 || be int || equal to program_mux_rate in pack_header<br />
|}<br />
<br />
[[Category:Container Formats]]</div>Renikrillhttps://wiki.multimedia.cx/index.php?title=CRYO_APC&diff=11769CRYO APC2009-07-17T05:40:56Z<p>Renikrill: /* HNM Movie Soundtracks */</p>
<hr />
<div>* Extensions: .APC, .HNM, .BF, .ZIK<br />
* Company: [[CRYO Interactive Entertainment]]<br />
<br />
This covers the audio format for one of the versions of CRYO's video formats.<br />
<br />
<br />
==Credit==<br />
This file comes from [http://www.wotsit.org wotsit.org] and was originally written by Valery V. Anisimovsky.<br />
<br />
== APC Audio Files==<br />
<br />
The music, sfx, speech and video (.HNM) soundtracks in some CRYO Interactive<br />
games are .APC stand-alone files. APC file has the following header:<br />
<br />
struct APCHeader<br />
{<br />
char szID[8];<br />
char szVersion[4];<br />
DWORD dwOutSize;<br />
DWORD dwSampleRate;<br />
LONG lSampleLeft;<br />
LONG lSampleRight;<br />
DWORD dwStereo;<br />
};<br />
<br />
''szID'' -- ID string, which is "CRYO_APC".<br />
<br />
''szVersion'' -- version ID string, all files in the mentioned games have this<br />
set to "1.20". Note that this field may, in principle, vary.<br />
<br />
''dwOutSize'' -- number of samples in the file. May be used for song length<br />
(in seconds) calculation.<br />
<br />
''dwSampleRate'' -- sample rate for the file.<br />
<br />
''lSampleLeft'' -- the initial value for the left sample (see below).<br />
<br />
''lSampleRight'' -- the initial value for the right sample (see below).<br />
<br />
''dwStereo'' -- this seems to be boolean stereo flag: if this is not zero, the<br />
audio stream in the file is stereo (music and partly video soundtracks),<br />
otherwise it's mono (sfx, speech).<br />
<br />
The resolution is NOT specified in the header, so the default value (16-bit)<br />
should be used.<br />
<br />
After the APCHeader IMA ADPCM compressed sound data comes. You may find<br />
IMA ADPCM decompression scheme description further in this document.<br />
<br />
== IMA ADPCM Decompression Algorithm ==<br />
<br />
During the decompression four LONG variables must be maintained for stereo<br />
stream: ''lIndexLeft, lIndexRight, lCurSampleLeft, lCurSampleRight'' and two --<br />
for mono stream: ''lIndex, lCurSample''. At the beginning of the file you must<br />
initialize ''lCurSampleLeft/Right'' variables to the values from APCHeader while<br />
''lIndexLeft/Right'' are initialized to zeroes.<br />
Note that LONG here is signed.<br />
<br />
Here's the code which decompresses one byte of IMA ADPCM compressed<br />
stereo stream. Other bytes are processed in the same way.<br />
<br />
BYTE Input; // current byte of compressed data<br />
BYTE Code;<br />
LONG Delta;<br />
<br />
Code=HINIBBLE(Input); // get HIGHER 4-bit nibble<br />
<br />
Delta=StepTable[lIndexLeft]>>3;<br />
if (Code & 4)<br />
Delta+=StepTable[lIndexLeft];<br />
if (Code & 2)<br />
Delta+=StepTable[lIndexLeft]>>1;<br />
if (Code & 1)<br />
Delta+=StepTable[lIndexLeft]>>2;<br />
if (Code & 8) // sign bit<br />
lCurSampleLeft-=Delta;<br />
else<br />
lCurSampleLeft+=Delta;<br />
<br />
// clip sample<br />
if (lCurSampleLeft>32767)<br />
lCurSampleLeft=32767;<br />
else if (lCurSampleLeft<-32768)<br />
lCurSampleLeft=-32768;<br />
<br />
lIndexLeft+=IndexAdjust[Code]; // adjust index<br />
<br />
// clip index<br />
if (lIndexLeft<0)<br />
lIndexLeft=0;<br />
else if (lIndexLeft>88)<br />
lIndexLeft=88;<br />
<br />
Code=LONIBBLE(Input); // get LOWER 4-bit nibble<br />
<br />
Delta=StepTable[lIndexRight]>>3;<br />
if (Code & 4)<br />
Delta+=StepTable[lIndexRight];<br />
if (Code & 2)<br />
Delta+=StepTable[lIndexRight]>>1;<br />
if (Code & 1)<br />
Delta+=StepTable[lIndexRight]>>2;<br />
if (Code & 8) // sign bit<br />
lCurSampleRight-=Delta;<br />
else<br />
lCurSampleRight+=Delta;<br />
<br />
// clip sample<br />
if (lCurSampleRight>32767)<br />
lCurSampleRight=32767;<br />
else if (lCurSampleRight<-32768)<br />
lCurSampleRight=-32768;<br />
<br />
lIndexRight+=IndexAdjust[Code]; // adjust index<br />
<br />
// clip index<br />
if (lIndexRight<0)<br />
lIndexRight=0;<br />
else if (lIndexRight>88)<br />
lIndexRight=88;<br />
<br />
// Now we've got lCurSampleLeft and lCurSampleRight which form one stereo<br />
// sample and all is set for the next input byte...<br />
Output((SHORT)lCurSampleLeft,(SHORT)lCurSampleRight); // send the sample to output<br />
<br />
HINIBBLE and LONIBBLE are higher and lower 4-bit nibbles:<br />
#define HINIBBLE(byte) ((byte) >> 4)<br />
#define LONIBBLE(byte) ((byte) & 0x0F)<br />
Note that depending on your compiler you may need to use additional nibble<br />
separation in these defines, e.g. ''(((byte) >> 4) & 0x0F)''.<br />
<br />
StepTable and IndexAdjust are the tables given in the next section of<br />
this document.<br />
<br />
Output() is just a placeholder for any action you would like to perform for<br />
decompressed sample value.<br />
<br />
Of course, this decompression routine may be greatly optimized.<br />
<br />
As to mono sound, it's just analoguous:<br />
<br />
Code=HINIBBLE(Input); // get HIGHER 4-bit nibble<br />
<br />
Delta=StepTable[lIndex]>>3;<br />
if (Code & 4)<br />
Delta+=StepTable[lIndex];<br />
if (Code & 2)<br />
Delta+=StepTable[lIndex]>>1;<br />
if (Code & 1)<br />
Delta+=StepTable[lIndex]>>2;<br />
if (Code & 8) // sign bit<br />
lCurSample-=Delta;<br />
else<br />
lCurSample+=Delta;<br />
<br />
// clip sample<br />
if (lCurSample>32767)<br />
lCurSample=32767;<br />
else if (lCurSample<-32768)<br />
lCurSample=-32768;<br />
<br />
lIndex+=IndexAdjust[Code]; // adjust index<br />
<br />
// clip index<br />
if (lIndex<0)<br />
lIndex=0;<br />
else if (lIndex>88)<br />
lIndex=88;<br />
<br />
Output((SHORT)lCurSample); // send the sample to output<br />
<br />
Code=LONIBBLE(Input); // get LOWER 4-bit nibble<br />
// ...just the same as above for lower nibble<br />
<br />
Note that HIGHER nibble is processed first for mono sound and corresponds to<br />
LEFT channel for stereo.<br />
<br />
== IMA ADPCM Tables ==<br />
<br />
LONG IndexAdjust[]=<br />
{<br />
-1,<br />
-1,<br />
-1,<br />
-1,<br />
2,<br />
4,<br />
6,<br />
8,<br />
-1,<br />
-1,<br />
-1,<br />
-1,<br />
2,<br />
4,<br />
6,<br />
8<br />
};<br />
<br />
LONG StepTable[]=<br />
{<br />
7, 8, 9, 10, 11, 12, 13, 14, 16,<br />
17, 19, 21, 23, 25, 28, 31, 34, 37,<br />
41, 45, 50, 55, 60, 66, 73, 80, 88,<br />
97, 107, 118, 130, 143, 157, 173, 190, 209,<br />
230, 253, 279, 307, 337, 371, 408, 449, 494,<br />
544, 598, 658, 724, 796, 876, 963, 1060, 1166,<br />
1282, 1411, 1552, 1707, 1878, 2066, 2272, 2499, 2749,<br />
3024, 3327, 3660, 4026, 4428, 4871, 5358, 5894, 6484,<br />
7132, 7845, 8630, 9493, 10442, 11487, 12635, 13899, 15289,<br />
16818, 18500, 20350, 22385, 24623, 27086, 29794, 32767<br />
};<br />
<br />
== HNM Movie Soundtracks ==<br />
<br />
There are several structural variants on the HNM6 format when in reference to its dependency on APC audio. The most common of them all is the .HNM A/V multiplex, which is not directly playable [externally] via the game's own DirectShow HNM core filter .dlls, since the APC audio - as a whole - is spanned across multiple blocks, and presents stuttering and agitated sound when decoded through directshow. This particular HNM6 variant occurs in Cryo games such as 'Egypt Kids' and 'Deo Gratias'.<br />
<br />
<br />
The second most common variant is the 'stand-alone' HNM6 video format. Unlike the aforementioned A/V mux; this variant incorporates no APC within the HNM file itself but rather, it refers to external and individual APC files which, as a rule, have the same file title.<br />
<br />
<br />
Rarely seen; there is another variant on the HNM6.<br />
Perhaps the most logical adaptation of Cryo's video format, it is a simple dub of APC over HNM. It does not span over different blocks, thus via directshow, it plays verbatim as it would in-game. This can be found in 'China: The Forbidden City' as .HNS files, as well as in 'UBIK' as .UBB files.<br />
<br />
Whether or not UBIK's .UBB are in any/many way(s) similar to the .UBB video used in Megarace 2, is yet to be documented.<br />
<br />
== APC Audio Files in BF Archives ==<br />
<br />
When stored in .BF resources, APC audio files are stored "as is", without<br />
compression or encryption. That means if you want to play/extract APC<br />
file from the BF resource you just need to search for (''szID'') id-string<br />
("CRYO_APC") and read APC header starting at the beginning position of<br />
found id-string. This will give you starting point of the file and the size<br />
of the file will be the sum of APCHeader size and the compressed audio stream<br />
size correspondent to (''dwOutSize'') header field (that is, (''dwOutSize'') for<br />
stereo stream and (''dwOutSize)/2'' for mono stream).<br />
<br />
== ZIK Audio Files ==<br />
<br />
In the game Chine music is in ZIK files. Most of them are simple RAW files:<br />
16-bit signed stereo 22050 Hz (no header), except for only one which is a<br />
regular WAV file. So, you can just load and play those ZIKs as RAWs (except<br />
for one which is WAV).<br />
<br />
==PC Games Using CRYO APC==<br />
*[http://www.mobygames.com/game/windows/atlantis-the-lost-tales Atlantis: The Lost Tales]<br />
*[http://www.mobygames.com/game/windows/sacred-amulet Aztec: The Curse in the Heart of the "City of Gold" a.k.a Sacred Amulet]<br />
*[http://www.mobygames.com/game/windows/egypt-ii-the-heliopolis-prophecy Egypt II]<br />
*[http://www.mobygames.com/game/odyssey-the-search-for-ulysses Odyssey: The Search For Ulysses]<br />
*[http://www.mobygames.com/game/china-the-forbidden-city China: The Forbidden City]<br />
* Atlantis 2<br />
* Zero Zone a.k.a Onderzoek 2098 [http://www.mobygames.com/game/windows/zero-zone] [http://en.wikipedia.org/wiki/ZeroZone]<br />
<br />
[[Category:Game Formats]]</div>Renikrillhttps://wiki.multimedia.cx/index.php?title=HNM4&diff=11768HNM42009-07-17T05:06:47Z<p>Renikrill: /* Games Using HNM4 */</p>
<hr />
<div>* Extension: hnm<br />
* Company: [[CRYO Interactive Entertainment]]<br />
* Samples: http://samples.mplayerhq.hu/game-formats/hnm/losteden-hnm4/<br />
<br />
HNM4 is the third generation of the Cryo HNM video format. At least two decoder-incompatible variation of this format is known. Main version, operates in 320x200x256 resolution and simplified 640x480x256 spin-off, used in ALIENS game. Both formats share same container structure.<br />
<br />
== File Format ==<br />
File header:<br />
dword signature - file signature, "HNM4"<br />
dword unknown1 - probably format version<br />
word width - width of the frame<br />
word height - height of the frame<br />
dword filesize - size of the entrie hnm file<br />
dword frames - number of frames<br />
dword taboffset - offset of the TAB chunk<br />
word bits - sound sample resolution<br />
word channels - number of sound channels<br />
dword framesize - frame allocation size (width * height)<br />
byte unknown2[16] - seems to be unused<br />
byte copyright[16] - "-Copyright CRYO-"<br />
<br />
The rest of the file organized on manner similar to [[HNM (1)]] format. All single-frame related chunks combined to superchunks, where each superchunk starts with 32-bit value, lower 24 bits of it indicates superchunk size and highest 8 bits - flags (unknown). Each chunk starts with another 24+8 bits length header followed by 4 bytes of chunk ID (where only 2 bytes can be actually used), and chunk data. Near the end of file usually TAB chunk located, it doesn't have an upper-level superchunk.<br />
<br />
=== PL Chunk ===<br />
Palette. Stored in same format as used in [[HNM (1)]].<br />
* ALIENS: However, non-zero bit 23 of ChunkId indicates that palette stored in complete 8-bits-per-component format, unlike regular 6-bits otherwise.<br />
<br />
=== IZ Chunk ===<br />
Keyframe. See video decompression below.<br />
<br />
=== IU Chunk ===<br />
Interframe. See video decompression below.<br />
<br />
=== SD Chunk ===<br />
Sound data. [[PCM#Differential_PCM|DPCM]]-encoded sound fragment.<br />
<br />
== Decoding Video ==<br />
=== Intraframes ===<br />
Intraframe decompression is simialar to [[HNM (1)]] 0xFE frames. But with a few changes. Chunk data starts with small 4-bytes header:<br />
word width - width of the frame<br />
byte height - height of the frame (only lower byte of it)<br />
byte mode - rendering mode (always 0xFE ?)<br />
<br />
Then immediately followed by LZ-packed raster (without 6-byte compression header as was used before). LZ decompression algorithm remains the same, but bitreader use 32-bits queue and processing bits from highest to lowest.<br />
<br />
* You can safely ignore width/height/mode fields of the frame header as original decoder always renders whole frame regardless specified values.<br />
<br />
=== Interframes ===<br />
==== HNM4 Interframe ====<br />
Packed interframe consist of one or more compression codes. Depending on the code's count field following cases possible:<br />
<br />
bits<br />
0..4 : count = 0<br />
5..7 : tag:<br />
0: copy next two bytes of input to the output<br />
1: skip (next byte of input) * 2 bytes of output<br />
2: skip (next word of input) * 2 bytes of output<br />
3: fill (next byte of input) * 2 of output with (next byte of input)<br />
else: finish the unpacking<br />
<br />
- or -<br />
<br />
0..4 : count <> 0<br />
5 : previous<br />
6 : backline<br />
7 : backward<br />
8 : swap<br />
9..23 : offset<br />
<br />
In this case for (count) pixel pairs, copy them from the (output + offset * 2 - 32768) of the current frame to the output. Flag bits modify various parameters of this scheme (multiple flags can be used):<br />
* previous - copy pairs from the previous frame<br />
* backline - first pixel located 2 lines above + (swap)<br />
* backward - advance source pixel pairs in backward order<br />
* swap - swap pair's pixels<br />
<br />
==== HNM4A Interframe ====<br />
HNM4A interframe is a simplified version of the HNM4 interframe. Code format:<br />
bits<br />
0..5 : count = 0<br />
6..7 : tag:<br />
0: skip (next byte of input) bytes of output<br />
1: draw 1x2 column of the output with next 2 bytes of input<br />
2: advance to the next line of output (but keep current x position)<br />
3: finish the unpacking<br />
<br />
- or -<br />
<br />
0..5 : count <> 0<br />
6 : previous<br />
7 : delta<br />
8..23 : offset<br />
<br />
For (count) 1x2 columns copy them from the (output + offset) to the output.<br />
* previous - copy column from the previous frame<br />
* delta - copy column from (output + offset - 65536)<br />
<br />
=== Postprocessing ===<br />
For HNM4 (but not HNM4A movies) you need to perform extra frame postprocessing by swapping pixels using following self-explaining example (assuming 4xN image):<br />
<br />
Just unpacked frame Final frame<br />
p0 p1 p2 p3 ==> p0 p2 p4 p6<br />
p4 p5 p6 p7 p1 p3 p5 p7<br />
... ...<br />
<br />
== Decoding Audio ==<br />
'''TODO'''<br />
<br />
== Games Using HNM4 ==<br />
* Lost Eden<br />
* Hardline<br />
* Aliens<br />
* Dragon Lore<br />
* Dragon Lore II<br />
* Treasure Hunter<br />
<br />
[[Category:Game Formats]]</div>Renikrill