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 23:08] – 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 | + | |
- | * Bitmap | + | |
- | * Scanline LUT | + | |
- | * 80% opacity layer | + | |
- | * Bitmap | + | |
- | * Scanline LUT | + | |
- | * 60% opacity layer | + | |
- | * Bitmap | + | |
- | * Scanline LUT | + | |
- | * 40% opacity layer | + | |
- | * Bitmap | + | |
- | * Scanline LUT | + | |
- | * 20% opacity layer | + | |
- | * Bitmap | + | |
- | * Scanline LUT | + | |
- | Any (FIXME: even the fully opaque) layer might be missing. | + | Depending on a file type, pixels are either uncompressed |
- | There are at least two types of FRM16 files - type 64 and type 68. Type 64 uses uncompressed pixels, while type 68 uses RLE. | + | In the older incarnations |
+ | 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. | ||
+ | |||
+ | 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 39: | 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 80?% layer | | + | | 0x14 | 4 | Bitmap |
- | | 0x18 | 4 | Data size for 60?% layer | | + | | 0x18 | 4 | Bitmap |
- | | 0x1c | 4 | Data size for 40?% layer | | + | | 0x1c | 4 | Bitmap |
- | | 0x20 | 4 | Data size for 20?% layer | | + | | 0x20 | 4 | Bitmap |
==== Layers ==== | ==== Layers ==== | ||
Line 52: | Line 40: | ||
==== Bitmap ==== | ==== Bitmap ==== | ||
- | In type 68 files, the first 4 bytes in a bitmap is a DWORD containing bitmap' | + | Pixel color is encoded as a 16bit word, with a 5-6-5 RGB encoding. FIXME: How are fully transparent pixels encoded? |
- | + | ||
- | Pixel color is encoded as a 16bit word, probably | + | |
Type 64 files do not use any compression. Each bitmap consists of width x height pixels of 2 bytes each. | Type 64 files do not use any compression. Each bitmap consists of width x height pixels of 2 bytes each. | ||
Line 65: | Line 51: | ||
__ __ ff fe ff fc 00 00 00 00 00 00 00 00 00 00 | __ __ 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) | (First one pixel (0x81 & 0x7f) is skipped, then two (0x42 & 0x3f) whitish pixels are copied, then a black pixel is copied 5 times) | ||
+ | |||
+ | In type 68 files, the first 4 bytes in a bitmap is a DWORD containing bitmap' | ||
+ | |||
+ | |||
==== Scanline Lookup Table, LUT ==== | ==== Scanline Lookup Table, LUT ==== | ||
- | Array of 32bit indices into pixel data pointing to beginnings of each image scanline. The first index is 0 in type 64 files, 4 in type 68 files. | + | Array of 32bit indices into bitmap |
^ Offset ^ Size ^ Description ^ | ^ Offset ^ Size ^ Description ^ | ||
- | | 0x00 | 2 | Offset of the 1st scanline (0 in type 64 files, 4 in type 68 files) | | + | | 0x00 | 4 | Offset of the 1st scanline (0 in type 64 files, 4 in type 68 files) | |
- | | 0x02 | 2 | Offset of the 2nd scanline | | + | | 0x04 | 4 | Offset of the 2nd scanline | |
| ...||| | | ...||| | ||
- | | height * 2 | 2 | Offset of the last scanline | | + | | height * 4 - 4 | 4 | Offset of the last scanline | |
==== References ==== | ==== References ==== |
formats/frm16.1285542530.txt.gz · Last modified: 2010-09-26 23:08 (external edit)