Yeah, this is controlled by the HAM in D2. From
http://www.descent2.com/ddn/specs/ham/ -
Code: Select all
//Offset 0x000008 - 910 textures a 2+20 bytes
UINT32 n_textures;
BITMAP_INDEX bitmaps[n_textures];
TMAP_INFO tmap_info[n_textures];
This (particularly the first two lines) is exactly what controls it. n_textures governs how many textures a level has access to; I don't believe it's designed with any "free space", but you could make some by increasing that number and appending new texture data in the next two blocks.
So how it works is more or less like this:
The D2 level file format basically contains a data structure for each cube. Part of this data structure describes the texture indexes, alignment and lighting for each side of the cube.
When D2 has a level loaded in memory and wants to render the cube, it doesn't use that texture index directly but "maps" it to another number that describes the index of the texture in the actual PIG. It does this by looking up the "level texture index" in that "bitmaps" array I quoted above.
An example - say you have a cube with rock021 as its primary texture. This has an index of 0 that will be stored in the level file (little trivia detail: you can't use rock021 for a secondary texture because 0 has a special meaning for those - it means there
is no secondary texture). It reads entry 0 from "bitmaps", which contains the number 722 - i.e. it's texture #722 in groupa.pig (or any other D2 PIG). So D2 then knows which bitmap to display for that side.
That "tmap_info" array is also important; that contains information on various "properties" of the texture. From bm.h in the D2 source (I chopped out an ifdef used for Miner for clarity):
Code: Select all
//tmapinfo flags
#define TMI_VOLATILE 1 //this material blows up when hit
#define TMI_WATER 2 //this material is water
#define TMI_FORCE_FIELD 4 //this is force field - flares don't stick
#define TMI_GOAL_BLUE 8 //this is used to remap the blue goal
#define TMI_GOAL_RED 16 //this is used to remap the red goal
#define TMI_GOAL_HOARD 32 //this is used to remap the goals
typedef struct {
ubyte flags; //values defined above
ubyte pad[3]; //keep alignment
fix lighting; //how much light this casts
fix damage; //how much damage being against this does (for lava)
short eclip_num; //the eclip that changes this, or -1
short destroyed; //bitmap to show when destroyed, or -1
short slide_u,slide_v; //slide rates of texture, stored in 8:8 fix
} __pack__ tmap_info;
That stuff is what you would have to tweak to get it to point to the right eclip - also contained in the HAM - and I believe those govern the animation timings and frame counts.
) take a look at how D2 manages that hopefully later today... I figure it's either through the HAM or hard-coded, but I should have the resources to figure it out somehow.