MOS files

Description

Most of the time, when a static graphic, such as a mini-map, or gui backgrounds need to be stored, they are stored as MOS files. MOS files are tiled bitmapped files. These files are probably stored as tiled files because of the compression advantage it gives. Since MOS files are usually not larger than the screen, no real logistical advantage is gained by breaking them into tiles. But, the difference between storing them as full-on 24-bit bitmaps is fairly large. Consider that a 24-bit or 32-bit bitmap with 640x480 pixels would be 921600 or 1228800 bytes, respectively, whereas the same file, in tiled form, using 64x64 tiles, would be 389120 bytes, and is still quite fast to load, since it can be loaded in blocks, unlike with most (stream-based) compression algorithms (notably, RLE). It does, however, rely on colors being clustered to some extent (i.e. a forest with a lake and a building has a lot of green in one area, a lot of blue in another, and a lot of brown in another, but the colors tend to be clustered, so there isn't too much image degradation by using this palette reduction.

MOS file versions

MOS V1

Overall structure

MOS V1 Header

OffsetSize (datatype)Description
0x00004 (char array)Signature ('MOS ')
0x00044 (char array)Version ('V1 ')
0x00082 (word)width (pixels)
0x000a2 (word)height (pixels)
0x000c2 (word)columns (blocks)
0x000e2 (word)rows (blocks)
0x00104 (dword)block size (in pixels)
0x00144 (dword)offset of palettes from start of file

MOS V1 Palettes

As in all of the BG files which contain palettes, these palettes are arrays of 256 RGBQUAD structures, which means they take 4 bytes per color. The first three are the ones of interest, though, because they code for blue, green, and red components respectively. The palette blocks are found in the same order as the pixel blocks they correspond to (i.e. by increasing column number, then by increasing row number).

MOS V1 Tile offsets

This section immediately follows the palettes. This is just an array of columns*rows dwords, which are the offsets from the beginning of the pixel data to each tile's pixel data. These pointers are in the same order as the palette data.

MOS V1 Tile data

These tiles are ordered in a left-to-right, top-to-bottom order, just as the palettes. The blocks on the right side and the bottom row are only as large as they need to be (i.e. width modulo 64 and height modulo 64) based on the width in pixels and the blocksize of 64 pixels. In general, the block layout looks like:

Image
Block 0,0
64*64 pixels
Block 1,0
64*64 pixels
Block 2,0
64x64 pixels
... Block (n-1),0
64*64 pixel
Block n,0
x*64 pixels
Block 0,1
64*64 pixels
Block 1,1
64*64 pixels
Block 2,1
64x64 pixels
... Block (n-1),1
64*64 pixel
Block n,1
x*64 pixels
... ... ... ... ... ...
Block 0,m
64*y pixels
Block 1,m
64*y pixels
Block 2,m
64*y pixels
... Block (n-1),m
64*y pixels
Block n,m
x*y pixels

MOSC V1

Overall structure

MOSC V1 Header

The MOSC V1 data is an entire MOS V1 resource compressed with zlib and with a 12-byte header prepended, as seen below.

OffsetSize (datatype)Description
0x00004 (char array)Signature ('MOSC')
0x00044 (char array)Version ('V1 ')
0x00084 (dword)Uncompressed data length

[ back to index ]