WED files

Description

This is a pretty meaty file as far as content goes. I believe I have most of it pinned down, but not all of it. Basically, it ties together the physical representation of the terrain with the tilesets. This is essentially, the map, without its containers, actors, and items. In this file is a representation of all the walls and doors, as well, grouped together by contiguity; this is presumably information used by pathfinding algorithms.

WED file versions

• V1.3: Baldur's Gate, Planescape: Torment, Icewind Dale, Baldur's Gate 2

WED V1.3

An area is drawn in tiles. We will refer to each location into which a tile can be drawn as a tile cell. The tile cells are numbered starting from 0 at the top-left corner, increasing by one as you move to the right. A tile cell's index is computed as y*width+x. Several overlays are drawn. Overlay 0 is drawn first, and if needed, other overlays are drawn. So, a tile cell's index is looked up in the tilemap structures. These 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. Next, if the tilemap structure indicates any overlays need to be drawn, the process is repeated using the appropriate overlay, along with its associated tilemap and tile indices. At least as of this version, the tiles in the tilesets appear to be hardcoded at 64x64, and the cells in the search map are, I believe, hardcoded at 16x16 pixels.

Overall structure:

• Header
• Overlays
• Secondary header
• Doors
• Tilemap structures
• Door tile cell indices
• Tile indices (lookup table)
• Wall groups
• Polgons
• Polygon indices (lookup table)
• Vertices

WED V1.3 Header

WED V1.3 Overlays

Each overlay is represented by a tileset. These overlays will each cover a part of the map. Which parts of the map have which overlays is coded for in the tilemap section. For instance, bodies of water are typically done as overlays in BG. (WTRIV is a tileset used for rivers, WTLAKE is a tileset used for lakes.)

WED V1.3 Secondary header

Consider this a "secondary header" of sorts. It holds more offsets. This probably sprang out of incompatibilities between earlier internal versions of the WED file (V1.0, V1.1, and V1.2 come to mind) and the current version.

WED V1.3 Doors

All the physical doors on a map are represented by this sort of structure. (If, that is, they can be opened.) Really, this doesn't have to be doors, but just anything which "acts like" a door -- i.e. has an opened and closed state, and which optionally blocks certain squares from being reached when closed, and doesn't block them when open. 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.

WED V1.3 Tilemap structures

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 this 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. Some tile cells are animated, and they will use a range of tile indices from the tile indices lookup table.

WED V1.3 Door tile cells

Each door has associated to it a range of tile indices in this array. When the door is opened or closed, all the tiles whose indices are contained in the specified region of this array, have their state toggled. This means that the tile becomes (un)passable and that the tile graphic is switched between the default and alternate tile graphic. (In short, these are indices into the tilemap array.)

WED V1.3 Tile index lookup table

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. This, then, is just a big array of little-endian 16-bit words.

WED V1.3 Wall groups

Representations of continuous walls and doors need to be stored to determine where the characters can and cannot walk. This is achieved by creating polygons for walls and grouping them together by connectivity. Doors in their open/closed state can be formed of an arbitrary number of polygons. For instance, a double door could be one polygon when it is closed, and two when it is open. These wall groups are sets of indices in the polygon indices lookup table, which in turn point into the polygon table.

WED V1.3 Polygons

A polygon is a list of vertices, along with some state information I haven't yet deciphered, and a minimum bounding box.

WED V1.3 Polygon index lookup table

Like all the lookup tables in these 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.

WED V1.3 Vertices

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

[ back to index ]