Posted by Heaven on April 15, 1998 at 20:10:41:

struct .256Header
{
long unknown1;
long unknown2;
long type; // ??? tm is 256, overhead for tm is 32
long unknown3;

char filler[48]

long palettes; // # of palettes? maybe just 1 or 0
long paletteOffset; // from the END of this header
long paletteLength; // 2080 bytes every time?
long paletteUnknown;

long unknown4;
long unknown5;
long unknown6;
long unknown7;

long sections; // # of textures/bitmaps in the file?? (18 for tm!)
long sectionInfoOffset; // offset from the END of this header to the section table
long sectionInfoLength; // 128 bytes per sectionInfo entry (18 * 128 = 2304 for tm)
long sectionInfoUnknown;

long bitmapDescriptors; // don't ask!
long bitmapDescriptorInfoOffset; // from the END of this header
long bitmapDescriptorInfoLength; // 64 bytes for each entry methinks
long bitmapDescriptorInfoUnknown; // btw, tm has none of these (bitmap descriptors)

long bitmapInfoHeaders; // ditto the don't ask above :)
long bitmapInfoHeaderOffset; // again, from the end of this header
long bitmapInfoHeaderLength; // 128 bytes each I believe
long bitmapInfoHeaderUnknown; // again, none for the tm

long godKnowsWhats;
long godKnowsWhatOffset;
long godKnowsWhatLength; // 32 bytes each???
long godKnowsWhatUnknown;

long colorMaps; // ??? this is that 65536 byte thing in the tm after the palette
long colorMapOffset; // in the tm this actually comes FIRST (0...255 is part of it)
long colorMapLength; // 65536 bytes for the maps methinks
long colorMapUnknown;

long colorMapIndices; // ??? no idea what this is
long colorMapIndexOffset; // unlike I originally thought, this came AFTER the 65536 in tm
long colorMapIndexLength; // 256 bytes each?
long colorMapIndexUnknown;

long unknowns[12]; // what appears to be 3 more possible tables

long unknown8;
long unknown9;
long headerLength; // 320 bytes
long tagLength; // length of data this header precedes

unsigned char filler2[64];
}; // 320 bytes

So to get the start of the texture maps you'd simply
add up all the Lengths in the above tables and add 320.
For the tm you end up getting 2080 (palette), 2304
(section table), 65536 (colorMap), and 256 (colorIndex).
The total is 70176. +320 = 70496. Add this to the
start of the training map .256 file (19936) and you
get where the training map textures and shadowmaps
begin, or 90432. All decimal. Down with Hex! :)

Anyway, that's the wrong way to do it. The right way
is to access the textures thru the section table
(sectionInfoOffset is where they begin). One entry for
each section (18 for the training map).

struct sectionInfoEntry
{
char filler1[64];

long offset; // from the END of the .256Header
long length; // 65536 + 52 bytes I think
long unknown2;
long unknown3;

char filler2[48];
}; // 128 bytes

Take the first entry in the training map's section table.
It has two values: the first one is 64 bytes into the
entry and is 70176. Add 320 to this to get the offset
(from the start of the .256 file) to the first texture.
Add 19936 to this to get the offset in the artsound.gor
file to the first texture (since 19936 is the start of
the training map's .256 file). Again, it's 90432.

The second entry is just how long the texture is. An
8 bit 256x256 image is 65536 bytes. Apparently each
texture has a 52 byte header the definition of which is
beyond me at the moment. :)

Now you Myth editing programmers can quickly write a
program to snatch a texture from any .256 file in Myth.
Oh. One more thing. It seems that in the 52 byte
header I mentioned is a value which determines what kind
of texture it is (shadow or "regular"). At least I
think. Anyway it's the 6th byte into the header, or
the 4th int value. Oh, shucks:

struct textureHeader
{
int u1, u2, u3;
int type; // 33 = shadow, 1185 = texture
int u4, u5, u6, u7;
char filler1[32]; // no clue
int u8, u9;
}; // 52 bytes

Care,
Heaven