Difference between revisions of "DoomEd"

From DoomWiki.org

[unchecked revision][checked revision]
m (Use wp interwiki template to link to Wikipedia)
Line 7: Line 7:
 
* The editor used ASCII text files to save level data, which was then compiled into a binary form by the node builder. This was useful during Doom development since the format in which the maps are read by the game changed (see the [[Alpha]] articles for more information on this subject).
 
* The editor used ASCII text files to save level data, which was then compiled into a binary form by the node builder. This was useful during Doom development since the format in which the maps are read by the game changed (see the [[Alpha]] articles for more information on this subject).
 
* The editor only saved lines and things. Vertices, sidedefs and sectors were extrapolated from line properties by the node builder. This explains some of the map errors contained in the IWADs, such as [[E3M8: Dis (Doom)|E3M8]].
 
* The editor only saved lines and things. Vertices, sidedefs and sectors were extrapolated from line properties by the node builder. This explains some of the map errors contained in the IWADs, such as [[E3M8: Dis (Doom)|E3M8]].
* For editing sector info, a sector [http://en.wikipedia.org/wiki/Inspector_window inspector] panel was present in the interface. Left-clicking inside a sector would use a flood-fill pattern to find all the lines bordering the area clicked and set their sector definitions to that defined in the panel. Right-clicking inside a sector would update the panel with the property of the chosen sector, presumably retrieved from the first line detected by the flood-fill algorithm.
+
* For editing sector info, a sector {{wp|Inspector window|inspector}} panel was present in the interface. Left-clicking inside a sector would use a flood-fill pattern to find all the lines bordering the area clicked and set their sector definitions to that defined in the panel. Right-clicking inside a sector would update the panel with the property of the chosen sector, presumably retrieved from the first line detected by the flood-fill algorithm.
 
* The map compiler creates sectors from lines with identical sectordefs. For this reason, Id mappers would put meaningless dummy tags on the sectordefs of lines whose sectors should not be merged despite being initially identical. This can notably be seen with stair builders.
 
* The map compiler creates sectors from lines with identical sectordefs. For this reason, Id mappers would put meaningless dummy tags on the sectordefs of lines whose sectors should not be merged despite being initially identical. This can notably be seen with stair builders.
 
* Things were represented by colored squares.
 
* Things were represented by colored squares.

Revision as of 15:28, 18 February 2015

This article is about the unreleased editor from id Software. For Geoff Allan's editor, see DoomEd 4.2

DoomEd was the level editor used by id Software to create levels. It was written in Objective-C for the NeXTSTEP operating system. Contrarily to editors created by the community, it did not work directly on WAD files, but only on a text format that was then compiled into a binary-format map by DoomBSP; both tools were meant to be used in tandem.


Although DoomEd or its source code was never released, a certain number of factoids have been revealed by developers, notably John Romero (who programmed it) and Michael Raymond-Judy.

  • The editor used ASCII text files to save level data, which was then compiled into a binary form by the node builder. This was useful during Doom development since the format in which the maps are read by the game changed (see the Alpha articles for more information on this subject).
  • The editor only saved lines and things. Vertices, sidedefs and sectors were extrapolated from line properties by the node builder. This explains some of the map errors contained in the IWADs, such as E3M8.
  • For editing sector info, a sector inspector panel was present in the interface. Left-clicking inside a sector would use a flood-fill pattern to find all the lines bordering the area clicked and set their sector definitions to that defined in the panel. Right-clicking inside a sector would update the panel with the property of the chosen sector, presumably retrieved from the first line detected by the flood-fill algorithm.
  • The map compiler creates sectors from lines with identical sectordefs. For this reason, Id mappers would put meaningless dummy tags on the sectordefs of lines whose sectors should not be merged despite being initially identical. This can notably be seen with stair builders.
  • Things were represented by colored squares.
  • A visual texture selector was included (at least for flats).
  • The X and Y offsets for texture alignment on sidedefs were called "firstrow" and "firstcol".
  • New textures could be created from patches from within the editor.
  • Line specials had names derived from their internal names in the Doom engine, e.g. "Button_Plat_Down_Wait_Up_Stay". The specials were listed alphabetically rather than through their numerical value.

Map source format

The format used to store map data is made of three parts: a header, a line block, and a thing block. An empty line separates each section.

The header is merely the line "WorldServer version 4". It is unknown if previous versions of WorldServer corresponded to editors for earlier Id games, or for the alpha versions of Doom.

The line block begins with a counter of the form "lines:<number>"; for example "lines:475" for E1M1. Line definitions follow in order immediately afterwards. A full line definition is of this form, describing first the vertices and the line attributes, then the first side's sidedef and sector, and finally the second side's sidedef and sector.

(<v1x>,<v1y>) to (<v2x>,<v2y>) : <flags> : <special> : <tag>
    <s1firstrow> (<s1firstcol> : <s1toptexture> / <s1bottomtexture> / <s1midtexture> )
    <s1floorheight> : <s1floorflat> <s1ceilingheight> : <s1ceilingflat> <s1lightlevel> <s1special> <s1tag>
    <s2firstrow> (<s2firstcol> : <s2toptexture> / <s2bottomtexture> / <s2midtexture> )
    <s2floorheight> : <s2floorflat> <s2ceilingheight> : <s2ceilingflat> <s2lightlevel> <s2special> <s2tag>

If the line is not double-sided, the second side's two lines of definitions are entirely omitted.

The thing block likewise begins with a counter of the form "things:<number>"; for example "things:138" for E1M1. Since things do not have to contain ancillary objects (vertexes, sides and sectors) in their own data, a thing definition uses a single line, of this form:

(<x>,<y>, <angle>) :<type>, <flags>

Possible release

In a January 2015 interview, John Romero stated, "I recently gave the source to DoomEd to somebody to put on OSX. So that may happen."[1]

Sources

References

  1. John Romero (20 January 2015). "Devs Play Doom." YouTube. Retrieved 21 January 2015.