Differences

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

--- falcon4:file_formats:rsc_idx_fileformat [2009-02-06 22:31]
lightning
+++ falcon4:file_formats:rsc_idx_fileformat [2009-02-07 07:02]
@@ Line 1: / Line 1: @@
-====== IDX/RSC file pairs======
-.RSC files in Falcon are "resource bundles".  A "resource bundle" is a type of file that can contain one or more (embedded) binary files, of varying types.  For example, they can contain images, sounds, and/or miscellaneous binary content.  A single .RSC file can (and often does) contain multiple resources, potentially of mixed type (i.e. a resource bundle file could contain several images, several sounds, and several binary files, all at once).
-The correspondingly-named .IDX file (located in the same folder as the .RSC file in question), stores an index of the contents of the .RSC file.  This index provides offset information to the location within the .RSC file's DATA section, where a specific resource's raw binary data begins, as well as the size, in bytes, of the resource's binary data, and some additional metadata describing the type of resource that can be found at that location.  The interpretation of the .RSC file's binary data, therefore, is dependent on the information provided in the corresponding .IDX file.
-**NOTE:** The .IDX file extension in Falcon refers to a variety of different kinds of index files.  The formats described
-below ONLY APPLY to .IDX files that index a corresponding .RSC (resource bundle) file.  Other types of .IDX files ARE NOT
-described below.
-**NOTE ON DATA TYPES AND ENDIAN-NESS:** The data type "long" refers to a 32-bit (double-WORD) data type.  A "short" refers to a 16-bit (double-byte, a.k.a single WORD) data type.  The byte order on disk is little-endian, so, for example, the following four sequential bytes on disk { ''%%0xDD%%'', ''%%0xC8%%'', ''%%0x3F%%'', ''%%0x02%%'' }, when treated as a "long", would translate to the value ''%%0x023FC8DD%%'' (the reverse sequence).
-===== .IDX FILE FORMAT (for .IDX files that index a corresponding .RSC file) =====
-==== .IDX FILE HEADER SECTION ====
-^Field Name        ^Offset (Hex)      ^Length (Bytes)    ^Data Type     ^Description^
-|Size         |  ''%%0x00%%''        |4                 |long          |The size (in bytes) of the data section in this .IDX file (i.e. the file length minus the header length)|
-|Version      |  ''%%0x04%%''        |4                 |long          |The version number of the file format being used for this .IDX file\\ (must match the version number of the corresponding .RSC file)\\ example: ''%%0x023fc8dd%%''|
-Immediately following the header section in the .IDX file, comes the data section.  Each record in the data section
-in the .IDX describes one resource that can be found in the corresponding .RSC file.
-==== .IDX FILE DATA SECTION ====
-The DATA section in the .IDX file contains one DATA record per embedded resource in the corresponding .RSC file.  Each DATA record in the .IDX file
-starts with 2 common fields (ResourceType and ResourceID).  The rest of the DATA record (and hence, the size of an individual data record) depends
-on the specific ResourceType that is specified for that record.
-=== INDIVIDUAL .IDX FILE DATA RECORD -- COMMON FIELDS ===
-NOTE: all field offsets given in the Offset column below, are relative to the start of the individual data record within the .IDX file, not the start of the .IDX file itself.  \\ For example, the **ResourceType** field for the first DATA record in the .IDX file begins at **relative offset** = ''%%0x00%%'' (**absolute offset** = ''%%0x08%%'', for the first DATA record in the .IDX file).
-----------------------------------------------------
-^Field^Offset(Hex)^Length (Bytes)^Data Type^Description^
-|ResourceType|''%%0x00%%''|4|long|The type of resource that this record points to.\\ Values for the ResourceType field can be one of the following:\\ \\ **Hex Value**%%   %%**Description**\\ **''%%0x64%%''**  Image resource (i.e. an embedded bitmap)\\ **''%%0x65%%''**  Sound resource (i.e. an embedded windows .WAV file)\\ **''%%0x66 %%''** Flat file resource (i.e. embedded arbitrary binary content)|
-|ResourceID|''%%0x04%%''|32|char[32]|A ''%%NULL%%''-terminated ASCII string that identifies this resource.|
-|NOTE: ALL fields that follow, inside of a single .IDX data record, depend on the specific resource type that is being described by that record.|||||
-=== ADDITIONAL FIELDS FOR   RESOURCE TYPE = 0x64 (Image resource) ===
-**TOTAL RECORD LENGTH:** (including the ResourceType and ResourceID fields): 60 bytes
-^Field Name^Offset (Hex)^Length (Bytes)^Data Type^Description^
-|Flags|0x24|4|long|Bit flags that describe the image format.\\ \\ Bitmasks: \\ \\ **EightBit** = ''%%0x00000001%%'' Image contains a 256-value (8-bit) palette; each image pixel is described by a single byte representing an index into the color palette array (stored separately).\\ \\ **SixteenBit** = ''%%0x00000002%%'' Each image pixel is described by 2 bytes, which, taken together as a 16-bit integer, provide 16 bits of color information per pixel.  When this flag is set, no separate palette array exists.\\ \\ **UseColorKey** = ''%%0x40000000%%'' The image uses the first color in the palette (or magenta, for non-paletted images) as the color key (transparency color) -- any pixels using that color should be rendered as transparent|
-|CenterX|''%%0x28%%''|2|short|Center X pixel (not used??)|
-|CenterY|''%%0x2A%%''|2|short|Center Y pixel (not used??)|
-|Width|''%%0x2C%%''|2|short|Width of the image, in pixels|
-|Height|''%%0x2E%%''|2|short|Height of the image, in pixels|
-|ImageOffset|''%%0x30%%''|4|long|Offset (in bytes) to the start of the image's pixel data, relative to the start of the .RSC file's DATA section. \\ \\ The actual size of the data starting at that location will be:\\ \\ (Width * Height) bytes long (for an 8-bit paletted image),\\  **or** \\ (Width * Height * 2) bytes long (for a 16-bit image)\\ \\ **Pixel data structure**\\  The first byte in the pixel data array in the .RSC file represents the upper-left pixel of the image.  \\ The last byte in the pixel data array in the .RSC file represents the lower-right pixel of the image.  \\  The pixel array is stored with the first (top) row's worth of columns first (i.e. byte 0=(row 0, column 0); byte 1=(row 0, column 1), byte M = (row 0, column =width)... (byte N = row=height, column=width)|
-|PaletteSize|''%%0x34%%''|4|long|Number of entries in the image's palette.  Each palette entry consists of 2 bytes (16 bits of color info per palette entry). \\  **NOTE:** PaletteSize = 0 for non-paletted images.|
-|PaletteOffset|''%%0x38%%''|4|long|Offset (in bytes) to the start of the image's color palette data array, relative to the start of the the .RSC file's DATA section. \\ \\  To convert the 16-bit color values from the palette data array (or from the raw pixel data, in the case of non-paletted images) to 32-bit ARGB color values, use the following (pseudocode): \\ <code>
-byte A = 0xFF; //alpha byte
-byte R = (thisPixelPaletteEntryValue & 0x7C00) >> 7; //red byte
-byte G = (thisPixelPaletteEntryValue & 0x3E0) >> 2; //green byte
-byte B = (thisPixelPaletteEntryValue & 0x1F) << 3; //blue byte
-</code>\\ The 16-bit color data in the palette is actually only using 15 bits (5 for red, 5 for green, and 5 for blue). \\ * The low-order (rightmost) 5 bits are the blue bits.\\  * The next higher-order (middle) 5 bits are the green bits.\\  * The next higher-order 5 bits after that (i.e. the leftmost 5 bits) are the red bits.\\ * The high-order bit is not used. \\ \\ The conversion (described above) works by first masking off the relevant bits for a particular color, and then shifting those bits left or right so that each color's bits occupy the 5 most-significant bits in that color's respective byte. \\ \\ After performing the above conversion, you can then combine all the component bytes togther into a single 32-bit integer, as follows (pseudocode): \\ <code>
-long argb = ((A << 24) | (R << 16) | (G <<8) | B);
-</code>|
-=== ADDITIONAL FIELDS FOR   RESOURCE TYPE = 0x65 (Sound resource) ===
-**TOTAL RECORD LENGTH:** (including the ResourceType and ResourceID fields): 52 bytes
-^Field Name^Offset (Hex)^Length (Bytes)^Data Type^Description^
-|Flags|''%%0x24%%''|4|long|Bit flags that describe the sound format. \\ \\ Bitmasks:\\ **???**|
-|Channels|''%%0x28%%''|2|short|Number of channels of audio data in the corresponding sound file.\\ \\  * 1 = mono, \\  * 2 = stereo\\ \\  **NOTE:** This is actually redundant, because this information is also contained in the resource's payload within the .RSC file's DATA section.|
-|SoundType|''%%0x2A%%''|2|short|This resource's Windows .WAV file encoding type.  This field actually contains the value of the **wFormatTag** member of the .WAV file's **WAVEFORMATEX** structure.\\ \\ **NOTE:** This is actually redundant, because this information is also contained in the resource's payload within the .RSC file's DATA section.|
-|Offset|''%%0x2C%%''|4|long|Offset to the start of the sound resource's .WAV file binary data relative to the start of the .RSC file's DATA section.|
-|HeaderSize|''%%0x30%%''|4|long|Size, in bytes, of the sound file's header section, located inside the resource's binary data payload within the .RSC file's DATA section.\\ \\  **NOTE:** The length (in bytes) of the sound resource's actual payload within the .RSC file's DATA section can be found by looking at the integer value occupying the 4 bytes starting at this resource's .Offset+4 in the .RSC file's DATA section itself. You need to add 8 to that value to get the total embedded .WAV file size, in bytes, starting at the .Offset itself. \\ \\ **Example:** \\ if the sound resource's Offset was set to ''%%0x00%%'', you would seek to location ''%%0x04%%'' (Offset+4) in the .RSC file's DATA section, then read the next 4 bytes into a "long" integer.  Add 8 to the value of that integer, and that's the number of bytes, starting at this resource's .Offset relative to the start of the .RSC file's DATA section, that make up the entire .WAV file binary for this resource.|
-=== ADDITIONAL FIELDS FOR   RESOURCE TYPE = 0x66 (Flat [i.e. binary] resource) ===
-**TOTAL RECORD LENGTH:** (including the ResourceType and ResourceID fields): 44 bytes
-^Field Name^Offset (Hex)^Length (Bytes)^Data Type^Description^
-|Offset|''%%0x24%%''|4|long|Byte offset of the flat resource's binary data relative to the start of the corresponding .RSC file's DATA section|
-|Size|''%%0x28%%''|4|long|Size, in bytes, of the flat resource's contents|
-===== .RSC file format =====
-==== .RSC FILE HEADER SECTION ====
-^Field Name^Offset (Hex)^Length (Bytes)^Data Type^Description^
-|Size|''%%0x00%%''|4|long|The size (in bytes) of the data section in this .RSC file (i.e. the file length minus the header length)|
-|Version|''%%0x04%%''|4|long|The version number of the file format being used for this .RSC file (must match the version number of the corresponding .IDX file)\\ example: ''%%0x023fc8dd%%''|
-==== .RSC FILE DATA SECTION ====
-Immediately following the HEADER section in the .RSC file, comes the DATA section.
-The DATA section extends from absolute offset ''%%0x08%%'' in the .RSC file, to the end of the file.  Individual records can be extracted from the .RSC file by first parsing the corresponding .IDX file in order to understand the types of resources that the .RSC file contains data for, as well as discovering those resources' locations and sizes within the .RSC file.
-**NOTE:** all values of all .Offset fields within indidivual records in the .IDX file, specify offsets **relative** to the **start** of the DATA section in the .RSC file.  For example, if the .IDX record specifies an offset of ''%%0x00%%'', the actual data would be located in the .RSC file starting at **absolute offset** = ''%%0x08%%'' (i.e., 0 bytes past the start of the DATA section, which itself starts at **absolute offset**=''%%0x08%%'')

PMC Editing Wiki

User Tools

Site Tools

Differences

Page Tools