This is an old revision of the document!
Table of Contents
FRM16
They seem to be cached form of .FRM files (which in turn are created from .TGA files) to speed up loading. In some games (Ricochet) it's possible to delete them and they get recreated automatically. Since Lionheart does not have .FRM files, it probably would not work here. They reside in cache/ subdir, which supports the theory above.
[
: quotes on FRM/FRM16 and JPEG-like compression]
[: links to convertors by Balder, Miloch, …]
There are at least two types - 64 and 68
Type 64 is a simple uncompressed bitmap with some indices in the end. They are used e.g. for area minimaps.
Type 68 is some encoded format - RLE and possibly some JPEG compression [: add quote]
Header (36 bytes)
| Offset | Size | Description |
|---|---|---|
| 0x00 | 2 | Signature (0x1032) |
| 0x02 | 2 | Anchor X ? |
| 0x04 | 2 | Anchor Y ? |
| 0x06 | 2 | Width in pixels (portraits = 90, areas = 779) |
| 0x08 | 2 | Height in pixels (portraits = 111, areas = 330) |
| 0x0a | 2 | Flags? Either 0 (normal) or 107 (immediate) |
| 0x0c | 2 | Type (64 or 68) |
| 0x0e | 2 | Unknown, possibly padding, always 0 |
| 0x10 | 4 | Data size for opaque layer |
| 0x14 | 4 | Data size for % layer |
| 0x18 | 4 | Data size for % layer |
| 0x1c | 4 | Data size for % layer |
| 0x20 | 4 | Data size for % layer |
Layers
Layer
| Offset | Size | Description |
|---|
Pixel Encoding, RLE
Type 64 files do not use any compression. Each pixel in encoded in a 16bit word, probably with a common 5-6-5 RGB? encoding.
Type 68 FRM16 files use Run Length Encoding, RLE. Each image line consists of a series of pixel runs. The scheme uses two highest bits in the first bytes of each run. If bit 7 is set, lower bits contain number of pixels to skip. If bit 7 is clear and bit 6 is set, lower bits contain number of 16bit pixels which follow. If both bits 7 and 6 are cleared, the lower bit contain a number of repetion of the following 16 bit word.