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.
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.
|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 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.)
|0x0000||2 (word)||Width (in tiles)|
|0x0002||2 (word)||Height (in tiles)|
|0x0004||8 (resref)||Name of tileset (resource type 0x3eb)|
|0x0010||4 (dword)||Offset to tilemap for this overlay|
|0x0014||4 (dword)||Offset to tile index lookup for this overlay|
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.
|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|
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.
|0x0000||8 (char array)||Name of door (matched on in AREA file?)|
|0x0008||2 (word)||Unknown... Open/closed? (1==closed)|
|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 used to represent door in "door open" state|
|0x0010||2 (word)||Count of polygons used to represent door in "door closed" state|
|0x0012||4 (dword)||Offset from start of file to polygons used to represent door in "door open" state|
|0x0016||4 (dword)||Offset from start of file to polygons used to represent door in "door 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 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.
|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 in tile index lookup table of secondary (alternate) tile (i.e. tile for open state, if tile has an open/closed state)|
|0x0006||1 (byte)||The upper 7 bits of this byte are a bitmap indicating which of the overlays are to be drawn. The 0th overlay (the base layer) is always drawn.|
|0x0007||3 (bytes)||These bytes are not understood...|
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.)
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.
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.
|0x0000||2 (word)||Start polygon index|
|0x0002||2 (word)||Polygon index count|
A polygon is a list of vertices, along with some state information I haven't yet deciphered, and a minimum bounding box.
|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.)|
|0x000a||2 (word)||Min X coord of bounding box|
|0x000c||2 (word)||Max X coord of bounding box|
|0x000e||2 (word)||Min Y coord of bounding box|
|0x0010||2 (word)||Max Y coord of bounding box|
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.
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.
|0x0000||2 (word)||X coordinate|
|0x0002||2 (word)||Y coordinate|
[ back to index ]