WED file format

Applies to:
BG1, BG1: TotS, BG2, BG2: ToB, PST, IWD, IWD:HoW, IWD:TotL, IWD2

General Description
This file format maps the layout of terrain to the tiles in the tileset, and adds structure to an area by listing its doors and walls.

Detailed Description
An area is a grid, with each 64*64 cell within the grid (called a tile cell) being a location for a tile. Tile cells are numbered, starting at 0, and run from top left to bottom right (i.e. a tile cell number can be calculated by y*width+x). As well the tiles for the main area graphics, an area can use overlays. Overlays are usually used for rivers and lakes. Each overlay layer is placed in a separate grid, which are stacked on top of the base grid. Areas also contain another grid, split into 16*16 squares, for the exploration map.
The process of drawing an area is outlined below:
The cell number acts as an index into a tilemap structure.
This give a "tile lookup index" which is an index into the tile indices lookup table.
The tile indices lookup table gives the index into the actual tileset, at which point, the tile is drawn.
The process is repeated for each required overlay (using the associated overlay tilemap / tile indices).

Overall structure:

Offset Size (data type) Description
0x0000 4 (char array) Signature ('WED ')
0x0004 4 (char array) Version ('V1.3')
0x0008 4 (dword) Number of overlays (including the base layer)
0x000c 4 (dword) Number of doors
0x0010 4 (dword) Offset (from start of file) to overlays
0x0014 4 (dword) Offset (from start of file) to secondary header
0x0018 4 (dword) Offset (from start of file) to doors
0x001c 4 (dword) Offset (from start of file) to door tile cell indices

Each overlay is mapped to a tileset. The sections of the area each overlay will cover is controlled by the tilemap section.

Offset Size (data type) Description
0x0000 2 (word) Width (in tiles)
0x0002 2 (word) Height (in tiles)
0x0004 8 (resref) Name of tileset
0x000c 2 (word) Unique tile count
0x000e 2 (word) Movement type
0x0010 4 (dword) Offset to tilemap for this overlay
0x0014 4 (dword) Offset to tile index lookup for this overlay

The "secondary header" contains more offsets, which would generally be found within the primary header. The secondary header and the extra information it contains was probably added due to incompatibilities between earlier internal versions of the WED format (V1.0, V1.1, and V1.2) and the current version.

Offset Size (data type) Description
0x0000 4 (dword) Number of polygons used to represent walls
0x0004 4 (dword) Offset to polygons
0x0008 4 (dword) Offset to vertices
0x000c 4 (dword) Offset to wall groups
0x0010 4 (dword) Offset to polygon indices lookup table

This section generally describes doors, though the concept can be extended to describe any object which acts like a door; i.e. has an open state and a closed state, and optionally blocks certain cells from being reached. The door tile cells for a given door are those cells which are impeded, and whose graphics change when this door is closed. See the door tile cell indices section for details.

Offset Size (data type) Description
0x0000 8 (char array) Name of door (matched on in AREA file?)
0x0008 2 (word) Open (0) / Closed (1)
0x000a 2 (word) First door tile cell index
0x000c 2 (word) Count of door tile cells for this door
0x000e 2 (word) Count of polygons open state
0x0010 2 (word) Count of polygons closed state
0x0012 4 (dword) Offset (from start of file) to polygons open state
0x0016 4 (dword) Offset (from start of file) to polygons closed state

For each tile cell in a overlay, there is one tilemap structure. These structures tell us which tile(s) from the tileset resource are to be used for the given tile cell. Each tile cell must have one tileset resource; those which are referenced by the door tile cells of a door must have 2 - one for the open state, and one for the closed state. If a tile cell is animated it will use a range of tile indices from the tile indices lookup table.

Offset Size (data type) Description
0x0000 2 (word) Start index in tile index lookup table of primary (default) tile
0x0002 2 (word) Count of tiles in tile index lookup table for primary (default) tile
0x0004 2 (word) Index from TIS file of secondary (alternate) tile (i.e. tile for closed state, if tile has an open/closed state) and also for overlays indication (tiles with marked overlay area, by "green" colour)
0x0006 1 (byte)
  • bit 0: Unused
  • bit 1: Draw overlay 1
  • bit 2: Draw overlay 2
  • bit 3: Draw overlay 3
  • bit 4: Draw overlay 4
  • bit 5: Draw overlay 5
  • bit 6: Draw overlay 6
  • bit 7: Draw overlay 7
0x0007 3 (bytes) Unknown

This is an array of indices into the tilemap array. Each door is associated with several elements of this array. When the open/closed state of the door is changed, the associated tiles represented by the elements in this array have their state toggled, i.e. the tile becomes (un)passable.

The 'tile map' structures reference indices into this table. The 'tile counts' in the tilemap table are counts of indices in this table. This maps tile indices from the WED tile indices into the appropriate tile indices for the particular tileset file which the overlay in question references. Each element in this array is a little-endian 16-bit word.

Outlines of objects (specifically walls and doors) need to be stored in order to determine when to dither creature animations (to represent moving "behind" a wall). Outlines are stored as a series of ordered vertices, creating a polygon. Doors can be represented by more than one polygon in either their open or closed state - this allows for double doors. These wall groups are sets of indices in the polygon indices lookup table, which in turn points into the polygon table. One thing worth remembering is that one wall group has the following dimensions : 10 tiles * 7.5 tiles, thus all areas should have the according to the background overlay amount of wall groups sections stored here i.e. area with dimensions 80*60 tiles should have 64 wall groups.

Offset Size (datatype) Description
0x0000 2 (word) Start polygon index
0x0002 2 (word) Polygon index count

A polygon consists of a list of vertices, a minimum bounding box and some unknown state information.
The order of vertices can be important when describing polygons
  • for doors wall, the vertices have to be listed clockwise, starting with the rightmost vertex first. If there are two or more vertex on the same rightmost vertical line, the lowest point should be listed first.
  • for normal walls, the vertices can be listed in clockwise or anti-clockwise order, starting with the most lowest vertex.
Offset Size (data type) Description
0x0000 4 (dword) Starting vertex index
0x0004 4 (dword) Count of vertices
0x0008 1 (unsigned byte) Indicates whether this polygon is a polygon or a hole (i.e. whether it is a section of impassability, or one of passability). The default behaviour is that wall shades animations from both sides.
bit 0 : Shade wall
bit 1 : Hovering.
bit 2 : Cover animations
bit 3 : Cover animations
bit 4 : Unknown
bit 5 : Unknown
bit 6 : Unknown
bit 7 : Door?
0x0009 1 (byte) Height
0x000a 2 (word) Minimum X coordinate of bounding box
0x000c 2 (word) Maximum X coordinate of bounding box
0x000e 2 (word) Minimum Y coordinate of bounding box
0x0010 2 (word) Maximum Y coordinate of bounding box

Like all the lookup tables in WED files, this maps a (start, count) pair (in this case, from the wall group table) into a set of polygon indices (from the polygon table). This is essentially a table of little-endian 16-bit integers which are indices into the polygon table.

This is a table of (x, y) pairs of vertices. Each x and y is a little-endian 16-bit integer representing an onscreen coordinate.

Offset Size (data type) Description
0x0000 2 (word) X coordinate
0x0002 2 (word) Y coordinate