User Tools

Site Tools


formats:frm16

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
formats:frm16 [2010-09-26 01:46] edheldilformats:frm16 [2011-11-21 22:36] (current) – [Scanline Lookup Table, LUT] edheldil
Line 1: Line 1:
 ==== FRM16 ==== ==== FRM16 ====
  
 +*.frm16 files are simple bitmap images, used for many things like UI elements, icons, minimaps, textures, portraits ... In Lionheart, even more of them is actually embedded as frames in .SEQ16 and .MDL16 files. They use 16 bits per color and 8 bits for transparency (the older format probably used between 2 and 3 bits for transparency).
  
-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.+Supposedly they are cached form of .FRM files which in turn are created from .TGA files. To speed up loading, they do not use any JPEG-type compression like FRM files and use only RLE and 16bit colors. They reside in Cache/ subdir, which supports the theory. In some related games (Ricochet) it'allegedly possible to delete .FRM16 files and get them recreated automatically from FRM filesUnfortunately there are not any .FRM files in Lionheart
  
-[FIXME: quotes on FRM/FRM16 and JPEG-like compression] +FRM16 file consists of a header and up to five layersEach layer consists of pixel data followed by a lookup table to first pixels of each image row.
-[FIXME: links to convertors by Balder, Miloch, ...]+
  
 +Depending on a file type, pixels are either uncompressed (type 64), or RLE-compressed (file type 68). Only the type 68 allows transparency.
  
-There are at least two types 64 and 68+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. 
  
-Type 64 is a simple uncompressed bitmap with some indices in the endThey are used e.g. for area minimaps.+However in Lionheart the layers are used differentlyIf 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 colorsThe 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.
  
-Type 68 is some encoded format - RLE and possibly some JPEG compression [FIXME: add quote]+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) |
 | 0x0a | 2 | Flags? Either 0 (normal) or 107 (immediate) | | 0x0a | 2 | Flags? Either 0 (normal) or 107 (immediate) |
 | 0x0c | 2 | Type (64 or 68) | | 0x0c | 2 | Type (64 or 68) |
-| 0x0e | 2 | Unknown, possibly padding, always 0 | +| 0x0e | 2 | Unknown, possibly padding, always 0 in standalone files 
-| 0x10 | 4 | Data size for opaque layer | +| 0x10 | 4 | Bitmap size for the 1st, opaque layer | 
-| 0x14 | 4 | Data size for layer | +| 0x14 | 4 | Bitmap size for the 2nd layer, unused 
-| 0x18 | 4 | Data size for layer | +| 0x18 | 4 | Bitmap size for the 3rd layer, unused 
-| 0x1c | 4 | Data size for layer | +| 0x1c | 4 | Bitmap size for the 4th layer, alpha 
-| 0x20 | 4 | Data size for layer |+| 0x20 | 4 | Bitmap size for the 5th layer, RGB |
  
 ==== Layers ==== ==== Layers ====
  
-Layer +Each layer consists of a bitmap and a scanline lookup table (LUT). 
-^ 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.+==== Bitmap ====
  
-Type 68 FRM16 files use Run Length EncodingRLE. Each image line consists of 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 is set, lower bits contain number of 16bit pixels which followIf both bits 7 and 6 are cleared, the lower bit contain a number of repetion of the following 16 bit word.+Pixel color is encoded as a 16bit wordwith 5-6-5 RGB encodingFIXME: How are fully transparent pixels encoded?
  
 +Type 64 files do not use any compression. Each bitmap consists of width x height pixels of 2 bytes each.
  
 +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.
 +
 +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)
 +
 +In type 68 files, the first 4 bytes in a bitmap is a DWORD containing bitmap's size in bytes. Since LUT's size is known (2 * height), it allows to read or skip the bitmap or whole layer without decoding it. However, the same number is already in the header, so its usefullness is unclear. 
 +
 +
 +
 +==== 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.1285465611.txt.gz · Last modified: 2010-09-26 01:46 by edheldil