.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.

(i.e. the file length minus the header length)|

.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.

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.

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).

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)|

that record.|||||

TOTAL RECORD LENGTH: (including the ResourceType and ResourceID fields): 60 bytes

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|

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)|

info per palette entry).
NOTE: PaletteSize = 0 for non-paletted images.|

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):

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

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):

long argb = ((A << 24) | (R << 16) | (G <<8) | B);

|

TOTAL RECORD LENGTH: (including the ResourceType and ResourceID fields): 52 bytes

NOTE: This is actually redundant, because this information is also contained in the resource's payload within the .RSC file's

DATA section.|

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.|

file's DATA section.|

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.|

TOTAL RECORD LENGTH: (including the ResourceType and ResourceID fields): 44 bytes

DATA section|

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.

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)