Mod:TEXBSI File Format
The TEXBSI files found in Redguard's fxart directory store texture data used for 3d models. There are 415 such files, with extensions ranging from 000 to 500. For example, TEXBSI.412 contains textures related to Cyrus.
This page outlines the format of these files in detail. It is assumed that you are familiar with hex-editing and base-16 numbers.
Each TEXBSI file is composed of multiple image structures, one following the other. These images may be animated, and the separate frames can share rows of pixels. The images in a file usually share some common elements; they may all be from the same tile set, or map to the same 3d model. The file containing the most images is TEXBSI.412 with 64, all of them ground textures.
Note that integers and shorts have little-endian byte order unless stated otherwise. Shown below is how the integer 12Ch would appear in each order.
- Little-endian: 2C 01 00 00
- Big-endian: 00 00 01 2C
Image structures begin with a 9 byte name identifier. A null image name (all 0 bytes) indicates the end of the texture file. If the name is non-null, it is followed by an integer representing the image structure's size in bytes. The image size does not include the 13 bytes taken by name and size fields.
|9 bytes||string||Image name|
|4 bytes||integer||Image size in bytes|
The image is then divided into a number of sub-records. All sub-records have a similar beginning format: a 4 byte name followed by a big-endian integer representing the sub-record's size in bytes. As before, this size does not include the first 8 bytes taken up by the name and size fields.
|4 bytes||string||Sub-record name|
|4 bytes||big-endian integer||Sub-record size in bytes|
The data that comes after the size field depends on the sub-record. The possible image sub-records are described below, in the order they appear.
- (0 bytes; this or IFHD required)
- The name probably stands for 'Bethesda Softworks Image Format'. Except for the last image in TEXBSI.357, BSIF is the sub-record used for images that are not animated.
- (44 bytes; this or BSIF required)
- This represents an 'Image Format Header', which is always a 1 followed by 43 0s. BSIF and IFHD sub-records cannot exist together.
- (26 bytes; required)
- BHDR contains information about the image, most importantly width, height, and the number of frames. The purpose of much of the other data is unknown.
|byte||0, 1||The images that have 1 are all animated effects such as fire and water.|
|byte||0, 1, 9|
|short||1 to 16||Number of frames|
|short||0 to 500; mostly 71|
|byte||0, 128, 163; mostly 0||The three images with 128 are fish, and the two with 163 are flames.|
|byte||0, 1, 2; mostly 1|
|short||0, 4; mostly 0|
- (768 bytes; optional)
- A color map, or palette, for defining custom colors for the current image. The data is 256 colors written in RGB triplets.
- Most images do not have a CMAP sub-record, so they rely on an external palette instead. These are found in the fxart directory as files ending in COL. The file format is identical to CMAP except for the first 8 bytes. WORLD.INI defines which color map should be used for each location.
- (Variable size; required)
- This sub-record contains all of the image's pixel data. If the image is not animated (number of frames defined in BHDR is 1) then the data is an array of
width * heightbytes. Each byte is an index in the current color map.
- If instead the image is animated then there is first a list of
height * number of framesinteger offsets. Each group of height offsets points to rows of bytes (width in length) for one frame. An offset with value 0 starts at the beginning of this offset list rather than after it.
- (0 bytes; required)
- Always the last sub-record of an image. Note that there is a space after the 'D'.
- Redguard-3dfiletest -- Test project that contains a class for loading and handling TEXBSI files.