This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
falcon4:file_formats:rsc_idx_fileformat [2009-02-06 21:50] lightning created |
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. | ||
- | |||
- | ===== .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%%''| | ||
- | |||
- | 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. | ||
- | |||
- | ==== .RSC FILE DATA SECTION ==== | ||
- | The .RSC file's DATA section begins at absolute offset ''%%0x08%%'' in the .RSC file, and extends to the end of the 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%%'') | ||