Differences

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

@@ 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
--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%%'')