formats:frm16
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
formats:frm16 [2010-09-26 21:26] – edheldil | formats:frm16 [2011-11-21 22:36] (current) – [Scanline Lookup Table, LUT] edheldil | ||
---|---|---|---|
Line 1: | Line 1: | ||
==== FRM16 ==== | ==== FRM16 ==== | ||
- | *.frm16 files are images, used for many things like UI elements, icons, minimaps, textures, portraits ... Also they are embedded in .SEQ16 and .MDL16 files. They use 16bits (2 bytes) | + | *.frm16 files are simple bitmap |
- | Allegedly | + | Supposedly |
- | FRM16 file consists of a header and up to five layers. | + | FRM16 file consists of a header and up to five layers. |
- | + | ||
- | * header | + | |
- | * Opaque layer | + | |
- | * Scanline LUT for the opaque layer | + | |
- | * 80% opacity layer | + | |
- | * Scanline LUT for the 80% layer | + | |
- | * 60% opacity layer | + | |
- | * Scanline LUT for the 60% layer | + | |
- | * 40% opacity layer | + | |
- | * Scanline LUT for the 40% layer | + | |
- | * 20% opacity layer | + | |
- | * Scanline LUT for the 20% layer | + | |
- | Any (FIXME: even the fully opaque) layer might be missing | + | Depending on a file type, pixels are either uncompressed |
- | [FIXME: quotes on FRM/FRM16 and JPEG-like compression] | + | In the older incarnations of the format, layers were probably a way to encode alpha (transparency) in FRM16 files - the first layer would be opaque (possibly with fully transparent pixels in type 68), the second layer would be 80% opacity and so on with the fifth one being 20% opacity. |
- | [FIXME: links to convertors by Balder, Miloch, ...] | + | |
+ | However in Lionheart the layers are used differently. If the image is type 68, the first layer is the same as above, but the second and third layers are never used. The fifth layer contains pixels which are semitransparent - but only their RGB colors. The alpha information for the fifth layer is in the fourth layer, but WITHOUT the RLE information. In other words, the alpha layer is unusable without the RGB one. It's stupid and makes incremental loading of type 68 images complicated. | ||
- | There are at least two types of FRM16 files - type 64 and type 68. Type 64 uses uncompressed pixels, while type 68 uses RLE. | + | Perhaps the 2nd and 3rd layers, unused in Lionheart, could be reused for height and normal maps for fake 3D effect (2.5D). |
+ | ==== Header ==== | ||
Header (36 bytes) | Header (36 bytes) | ||
^ Offset ^ Size ^ Description | ^ Offset ^ Size ^ Description | ||
| 0x00 | 2 | Signature (0x1032) | | | 0x00 | 2 | Signature (0x1032) | | ||
- | | 0x02 | 2 | Anchor X ? | | + | | 0x02 | 2 | Anchor X | |
- | | 0x04 | 2 | Anchor Y ? | | + | | 0x04 | 2 | Anchor Y | |
| 0x06 | 2 | Width in pixels (portraits = 90, areas = 779) | | | 0x06 | 2 | Width in pixels (portraits = 90, areas = 779) | | ||
| 0x08 | 2 | Height in pixels (portraits = 111, areas = 330) | | | 0x08 | 2 | Height in pixels (portraits = 111, areas = 330) | | ||
Line 38: | Line 27: | ||
| 0x0c | 2 | Type (64 or 68) | | | 0x0c | 2 | Type (64 or 68) | | ||
| 0x0e | 2 | Unknown, possibly padding, always 0 in standalone files | | | 0x0e | 2 | Unknown, possibly padding, always 0 in standalone files | | ||
- | | 0x10 | 4 | Data size for opaque layer | | + | | 0x10 | 4 | Bitmap |
- | | 0x14 | 4 | Data size for % layer | | + | | 0x14 | 4 | Bitmap |
- | | 0x18 | 4 | Data size for % layer | | + | | 0x18 | 4 | Bitmap |
- | | 0x1c | 4 | Data size for % layer | | + | | 0x1c | 4 | Bitmap |
- | | 0x20 | 4 | Data size for % layer | | + | | 0x20 | 4 | Bitmap |
==== Layers ==== | ==== Layers ==== | ||
- | Layer | + | Each layer consists of a bitmap and a scanline lookup table (LUT). |
- | ^ Offset ^ Size ^ Description | + | |
- | ==== Pixel Encoding, RLE ==== | ||
- | Pixel color is encoded as a 16bit word, probably with a common 5-6-5 RGB? encoding. FIXME: How are fully transparent pixels encoded? | + | ==== Bitmap ==== |
- | Type 64 files do not use any compression. Each layer contains all Width x Height | + | Pixel color is encoded as a 16bit word, with a 5-6-5 RGB encoding. FIXME: How are fully transparent |
- | Type 68 FRM16 files use Run Length Encoding, RLE. Each image scanline | + | Type 64 files do not use any compression. Each bitmap |
+ | Type 68 FRM16 files use Run Length Encoding, RLE. Each bitmap line consists of variable number of pixel runs. The RLE scheme uses two highest bits in the first byte of each run. If bit 7 is set, bits 0-6 contain number of pixels to skip in the resulting image. If bit 7 is clear and bit 6 is set, bits 0-5 contain number of 16bit pixels which follow. If both bits 7 and 6 are cleared, bits 0-5 contain a number of repetitions of the following 16 bit pixel. | ||
- | ==== Color Encoding ==== | + | For example: |
+ | 81 42 ff fe ff fc 05 00 00 | ||
+ | would result in | ||
+ | __ __ ff fe ff fc 00 00 00 00 00 00 00 00 00 00 | ||
+ | (First one pixel (0x81 & 0x7f) is skipped, then two (0x42 & 0x3f) whitish pixels are copied, then a black pixel is copied 5 times) | ||
- | Pixels' | + | In type 68 files, the first 4 bytes in a bitmap |
+ | |||
+ | |||
+ | |||
+ | ==== Scanline Lookup Table, LUT ==== | ||
+ | |||
+ | Array of 32bit indices into bitmap pointing to beginnings of each bitmap scanline. The first index is 0 in type 64 files, 4 in type 68 files. | ||
+ | |||
+ | ^ Offset ^ Size ^ Description ^ | ||
+ | | 0x00 | 4 | Offset of the 1st scanline (0 in type 64 files, 4 in type 68 files) | | ||
+ | | 0x04 | 4 | Offset of the 2nd scanline | | ||
+ | | ...||| | ||
+ | | height * 4 - 4 | 4 | Offset of the last scanline | | ||
+ | |||
+ | ==== References ==== | ||
+ | |||
+ | [FIXME: quotes on FRM/FRM16 and JPEG-like compression] | ||
+ | [FIXME: links to convertors by Balder, Miloch, | ||
formats/frm16.1285536373.txt.gz · Last modified: 2010-09-26 21:26 by edheldil