From ec32cf41f916fc34c03d2844684631bee39005ad Mon Sep 17 00:00:00 2001 From: Ian C Date: Thu, 9 Jun 2011 13:57:32 +0000 Subject: Added copies of old numbered releases. --- doc/overview.htm | 881 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 881 insertions(+) create mode 100644 doc/overview.htm (limited to 'doc/overview.htm') diff --git a/doc/overview.htm b/doc/overview.htm new file mode 100644 index 0000000..4e682a8 --- /dev/null +++ b/doc/overview.htm @@ -0,0 +1,881 @@ + + + + + +viDOOM - Free Software DOOM editor + + + + +

viDOOM Overview

+ +

Introduction
Why bother?
Supported systems
Configuration
- Environment
- VIDOOM.INI
- Config file
+

+ +

Introduction

+ +

viDOOM is a Free Software DOOM editor. It supports the +following id produced +games:

+ +

Doom
The Ultimate Doom
Doom 2 - Hell On Earth
Final Doom

+ +

Note that in accordance with id software's wishes you are only +allowed to generate edited levels for the game if you have a +full, registered version of the game.

+ +

viDOOM is fully configurable through config files, so it can +be expanded to accommodate the BOOM and ZDOOM extensions. Well, +once I've found out the slight difference in format of WAD file +that seems to accompany them too.

+ +

Why bother?

+ +

Good question. Anyone who has ever used them will know there +are a number of very good DOOM editors available (links to lots +of them can be found at Doomworld +and all good FTP servers).

+ +

However, I always felt a bit clumsy using them, and in true +hacker fashion I decided writing one I could use would be easier +then reading the instructions for the others. Hence viDOOM.

+ +

I reasonably like the way viDOOM works, so I release it on the +off chance other people may too.

+ +

Supported systems

+ +

As with most Free Software viDOOM is primarily distributed as +source code. The source is fairly ANSI C compliant, and therefore +the core of viDOOM should compile on all operating systems. The +current distribution includes the hardware dependent routines for +the following platforms:

+ +

Protected-mode 32-bit MSDOS (Windows 9x / MSDOS + DPMI)

+ +

Environment

+ +

If defined in the environment, the value of VIDOOM_DIR +will be made the current directory as soon as viDOOM starts. This +is important as the following initialisation files are expected +to be in the current directory when viDOOM starts.

+ +

Note:
+How this environment is set will differ from system. Basically +viDOOM just calls the C library getenv() function. So,. +for instance in a Unix type system this could be:

+ +

+
% setenv VIDOOM_DIR $HOME/viDOOM
+ or
+ % export VIDOOM_DIR $HOME/viDOOM
+

+ +

Whereas in DOS/DJGPP version this could be:

+ +

+
C:\> set VIDOOM_DIR=C:\viDOOM
+

+ +

Initialisation File - VIDOOM.INI

+ +

On starting viDOOM will look for a file in the current +directory called vidoom.ini. This file tells +viDOOM what version of DOOM it is expected to be editing, the +configuration for that version of DOOM and the editor +configuration. The general format of the INI file is:

+ +

[Section] +identifier=value +

+ +

Blank lines and lines starting with a comment character (#) +are ignored. The following sections and identifiers are explained +below.

+ +

[Game]
[Editor]
[viDOOM]
[Check Linedef]
[Node Builder]
[GUI]
[Game Name]

+ +

After reading VIDOOM.INI, then a defined config file is also read.

+ +

[Game]

+ +

Controls for the version of DOOM

+ + + + + + + + + + +

`game`	Use this to say which version of DOOM + you will be editing. The following values are allowed: + Doom + Ultimate Doom + Doom 2 + TNT: Evilution + Plutonia Experiment + ZDoom + +
ask	If set to yes then on starting + viDOOM will ask for the game type to edit.

+ +

[Editor]

+ +

Global editor configuration

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

`ask_middle_on_2sided`	When creating a new sector and the + sector has a two-sided boundary asks whether a middle + texture should be asked for. Allowable values yes + and no
`auto_block_linedefs`	When linedef flags are altered and this + is set to yes, linedefs that were + 2-sided and are now 1-sided have the impassible flags + automatically set. + Likewise linedefs that were 1-sided and are now 2-sided + have the impassible flag automatically cleared. + If set to no no action is taken when these events + happen.
`bright`	Describes a gamma value applied to any + textures, flats and sprites read in from the DOOM WAD + files. Allowable values are any floating point number.
`clear_on_menu`	If set to yes then once + the pop-up menu has been used to modify the selected + objects they are automatically unselected.
`clear_on_move`	If set to yes then once + the selected objects have been moved they are + automatically unselected.
`default_light_level``+``default_floor_height``+``default_ceiling_height`	Describes the default light, floor and + ceiling height for created sectors. Note that if a sector + is created within another sector, the values for that + sector, rather than these defaults, are used.
`default_edit_mode`	Defines the default edit mode when + loading a new map into the editor. Possible values are: + sector + linedef + thing + vertex + multi + +
`default_scale`	The starting scale used in the editor.
`grid`	Use this to say whether the grid will be + shown on screen while editing. Allowable values are yes + and no.
`grid_lock`	Use this to say whether inserted and + moved object in the editor will be snapped on a grid. + Allowable values are yes and no. +
`grid_size`	Describes the size of the grid used by + the above items. Allowable values are integer values + greater than two.
`hover_select`	When editing object in a DOOM level this + alters the way that viDOOM works if the right mouse + button is used over an unselected object. The allowable + values, and their affects are: + none - nothing is done. The + right mouse button works as expected. + add - the object the mouse is + over is added to the selected objects before + displaying the menu. + single - the object the mouse is + over is made the sole selected object before + displaying the menu. + +
`insert_select`	When inserting new objects in a DOOM + level this alters the way that viDOOM selects the objects + after creation. The allowable values, and their affects + are: + none - nothing is done. The new + object is left unselected. + add - the new object is added to + the selected objects. + single - the new object is made + the sole selected object. + +
`linedef_select`	Defines who many pixels around a LINEDEF + the bounding box stretches when selecting a line.
`merge_linedef`	If you overlay vertexes on top of each + other you can merge vertexes. Once these vertexes are + merged checks are made to see whether linedefs share + these vertexes, and hence overlap. This option controls + what happens when these overlapping linedefs are found. + The possible values are: + always - always merge the + overlapping linedefs without any prompting. + ask - confirms with the user + before merging linedefs or not as requested. + never - never merge overlapping + linedefs. + +
`new_2sided_select`	When linedefs have there flags set so + that a new left sidedef is added to it controls how the + altered linedefs are selected. Possible values are: + select - clears the currently + selected linedefs (if any) and selects the + linedefs that have new double sides. + ask - confirms with the user. If + the user opts to select the linedefs, the current + selection is cleared and the altered linedefs + selected. + never - never select the altered + linedefs. Note that a notice is still displayed + so that you know new left sidedefs have been + created. + +
`sector_move`	Defines which linedefs are actually + moved when moving a sector. Possible values are: + all - move all linedefs that + border the sector. + right - move only linedefs that + have this sector to their right. + left - move only linedefs that + have this sector to their left. + +
`show_full_linedef_info`	If set to yes then in + the linedef edit + display the linedef type will be shown as the full + linedef name as defined in the config + file. If set to no then linedef type + will be displayed as a hex value and it's class.
`tag_highlight`	If set to yes then the + tag highlighting mode is enabled by default in sector and + linedef modes.
`vertex_radius`	Describes the size of the box around a + VERTEX which is used to select the VERTEX while editing. + Recommended values are any integer greater than four.
`width``+``height`	Describes the size of the display used + by viDOOM. viDOOM expects a resolution of at least + 640x480.

+ +

[viDOOM]

+ +

Main menu configuration

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

`initial_empty_map`	If set to yes then on + startup viDOOM will have an empty map, either MAP01 or + E1M1, ready for editing.
`load_flats`	If set to yes then the graphics + for the flats will be loaded so they can be selected + graphically. If set to no then flats are selected + just using their name. + This is provided as the graphics reading is not very + efficient and can be slow on certain machines.
`load_textures`	If set to yes then the graphics + for the textures will be loaded so they can be selected + graphically. If set to no then textures are + selected just using their name. + This is provided as the graphics reading is not very + efficient and can be slow on certain machines.
`load_sprites`	If set to yes then the graphics + for the things will be loaded so they can be selected + graphically. If set to no then things are selected + just using their name. + This is provided as the graphics reading is not very + efficient and can be slow on certain machines.
`map_clear_warning`	If set to yes then a warning is + displayed whenever an option is chosen that will replace + the currently edited map with another, if the editor has + been used since the level's loading/creation.
`map_exit_warning`	If set to yes then a warning is + displayed if exit is chosen and the editor option has + been used.
`overwrite_warning`	If set to yes then a warning is + displayed if you save a map over a file that already + exists.
`show_titlepic`	If set to yes then the title + picture for the version of DOOM you are editing will be + displayed on the main title screen.
`sort_flat_names`	If set to yes then when selecting + ceiling or floor flats they will be sorted into + alphabetical order. If set to no they are simply + in the order they appear in the IWAD file.
`sort_texture_names`	If set to yes then when selecting + wall textures they will be sorted into alphabetical + order. If set to no they are simply in the order + they appear in the IWAD file.

+ +

[Check LINEDEF]

+ +

This defines how the Check LINEDEF function +in the editor (see editing +for details) operates. Note that part of the configuration for +this command also occurs in the config +file. This is required as texture names can be different in +different versions of DOOM. The following options are definable +within the INI file:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

`assume_yes`	If this is set to yes + then any time a question would be asked to see if it's OK + to remove a texture that viDOOM considers unnecessary + then it will be removed without asking. Likewise when + asking to add missing textures the texture picklist will + appear (with the linedef number and what is to be set in + the title) without any prompting.
`check_1side_lower`	If set to yes then when + a sidedef is attached to a one-sided linedef and there is + a lower texture defined viDOOM will ask if it's OK to + remove it.
`check_1side_middle`	If set to yes then when + a sidedef is attached to a one-sided linedef and there is + no middle texture defined viDOOM will ask if it's OK to + define it.
`check_1side_upper`	If set to yes then when + a sidedef is attached to a one-sided linedef and there is + an upper texture defined viDOOM will ask if it's OK to + remove it.
`check_2side_lower`	If set to yes then when + a sidedef is attached to a two-sided linedef which is + between two sectors with different floor heights and + there is no lower texture defined viDOOM will ask if it's + OK to define it.
`check_2side_middle`	If set to yes then when + a sidedef is attached to a two-sided linedef which is + between two sectors and there is a middle texture defined + viDOOM will ask if it's OK to remove it.
`check_2side_upper`	If set to yes then when + a sidedef is attached to a two-sided linedef which is + between two sectors with different ceiling heights and + there is no upper texture defined viDOOM will ask if it's + OK to define it.
`check_2side_same_sector`	If set to yes then when + a sidedef is attached to a two-sided linedef which is + wholly within one sector and there are any textures + defined viDOOM will ask if it's OK to remove them.

+ +

[Node Builder]

+ +

Node Builder configuration - used to build nodes for maps +automatically when saving.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

`always_view_output`	Normally viDOOM will only show the + output from the build command if it fails for some + reason. Setting this to yes means any + output from the node builder will be displayed + regardless.
`command`	Defines the command used to execute the + node builder. e.g. `command=c:\bsp\bsp.exe` +
`ignore`	If set, then any saved filename that + includes this string will not be passed through the node + builder. This is useful so that structures for merging + into other maps (see editing + for details) need not be put through the node building + process. e.g. if set to `ignore=str` + Then saving a map named MAP01.WAD + will be passed through the node builder, whereas WALL_STRUCT.WAD + would not be. + Another important use for this is to leave a back door + where you can save a WAD without it being passed through + the node builder if anything goes wrong with trying to + build the map. +
`infile`	Defines the format for the infile + parameter to the node builder. Any occurrence of the '%' + character will be replaced with the full path of the map + being saved. e.g. `infile=%` +
`outfile`	Defines the format for the outfile + parameter to the node builder. Any occurrence of the '%' + character will be replaced with the full path of the map + being saved. e.g. `outfile=-o %` + Note that if your node builder does not allow the + input and output file to be the same then it is + permissible to put extra characters after + the % that will get tacked onto the end of the name, e.g. + `outfile=-o %_NEW` +
`in_before_out`	Defines the order of the the arguments + to the node builder. If set to yes then + the node builder is invoked as: `command infile + outfile` + If set to no then the command is + built as: + `command outfile infile` +
`use`	If set to yes then the + node builder described above is used on any maps being + saved. If set to no then the map is + saved and the nodes must be built outside of viDOOM.

+ +

[GUI]

+ +

GUI configuration. All the values in this section are an RGB +triplet defined as an hex number, i.e. 0xRRGGBB. The +following values can be set from the INI file.

+ + + + + + + + + + + + + + + + + + + + + + + + + + +

`gui_hi`	The brightest colour used to draw the 3D + looking interface.
`gui_mid`	The medium colour used to draw the 3D + looking interface.
`gui_lo`	The darkest colour used to draw the 3D + looking interface.
`gui_text`	The colour of text.
`gui_textshadow`	The colour of the shadow behind text. + This is only really used by viDOOM's own portable GUI + routines. If set to the same value as text + then no shadows are drawn.
`gui_bold`	The colour of bold text (used for + titles)

+ +

[Game name]

+ +

One of these sections appears for each possible setting of the +game variable in the [Game] section. These are:

+ +

[Doom]
[Ultimate Doom]
[Doom 2]
[TNT:Evilution]
[Plutonia Experiment]
[ZDoom]

+ + + + + + + + + + + + + + + + + + + + + + +

`iwad`	Defines the path to the IWAD for this + game.
`pwad_dir`	Defines the default load/save directory + for editing PWAD files.
`level_style`	Defines the level naming convention for + the game. Allowable values are: + Doom - allows level names E1M1 to E3M9 + Ultimate Doom - allows level names E1M1 to + E4M9 + Doom 2 - allows level names MAP01 to MAP32 + +
`preload`	Lists a number of PWAD files to preload + on startup. PWAD files are separated by ; and the full + path is expected.
`vidoom_config`	Defines the config + file for this version of DOOM. This defines the + values used for defining things, linedefs, sectors and so + on. + viDOOM is currently supplied with doom.cfg and doom2.cfg. + + It is planned to soon include a zdoom.cfg so that + ZDOOM/BOOM special features can be added to levels.

+ +

Config file

+ +

There is two config files supplied with viDOOM, doom.cfg +and doom2.cfg. Each file is comprised of +sections followed by the data expected in each section. Each +section is defined by a line like:

+ +

%SECTION_NAME

+ +

While the data lines are on individual lines with the pipe (|) +character used to separate fields, e.g.

+ +

Field 1|Field 2

+ +

Blank lines and lines starting with a comment character (#) +are ignored. The following sections are defined:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

`%INCLUDE_FILES`	Defines any other config files to + include before processing this one. Simply type the + filenames to be included on individual lines.
`%THING_CLASSES`	Defines the classes to group THINGs into + in the editor picklists. Each line is in the form + "Class Name\|Colour". Note that colour is + defined as an hexadecimal number with the most + significant byte for RED, the middle byte for BLUE and + the least significant byte for GREEN. e.g. `Monster\|0xff0000` +
`%LINEDEF_CLASSES`	Defines the classes to group LINEDEF + types into in the editor picklists. Each line is a class + name.
`%SECTOR_CLASSES`	Defines the classes to group SECTOR + types into in the editor picklists. Each line is a class + name.
`%THING_TYPES`	Defines the names and IDs of the THINGs + supported by DOOM. Each line is in the form + "Class\|Name\|ID\|Radius\|Sprite Name". e.g. `Monster\|Former + Human\|3004\|20\|POSSA1` +
`%THING_FLAGS`	Defines the flags used when defining + THINGs. Each line is in the form "Bit + Number\|Name\|Shorthand Name". e.g. `0\|Skill 1 + and 2\|Sk 1/2` +
`%LINEDEF_TYPES`	Defines the names and IDs of the LINEDEF + types supported by DOOM. Each line is in the form + "Class\|ID\|Name", e.g. `Special\|48\|Scrolling + wall` + Note: Please note that the text for + the LINEDEF types in the supplied config files is taken + directly from the Unofficial Doom Specs (see the thanks page for details). +
`%LINEDEF_FLAGS`	Defines the flags used when defining + LINEDEFs. Each line is in the form "Bit + Number\|Name\|Shorthand Character". e.g. `0\|Impassible\|I` +
`%LINEDEF_FLAGS_EXTRA`	Configuration so that viDOOM knows which + bits control certain functions. If more that one line + appears in this section then the last one is used. The + form of the line is "Bit number controlling + 2-sided\|Bit controlling Impassible\|Bit controlling lower + unpegged\|Bit controlling upper unpegged". e.g. `2\|0\|3\|4` +
`%LINEDEF_DEFAULTS`	This section must not appear before + %LINEDEF_FLAGS_EXTRA and defines the bit patterns for + various linedef styles. These are used in the editor so + that defining a type of LINEDEF can be quickly done when + creating them. The format of each line is + "Name\|Flags value", e.g. `2-sided + wall\|0x47` +
`%SECTOR_TYPES`	Defines the names and IDs for the + different sector types. Each line is in the form + "Class\|ID\|Long name\|Short name". e.g. `Damage/Lights\|4\|Lose + -10/20% health & blink lights 0.5 sec\|-10/20% & + 0.5 blink` +
`%SECTOR_STYLES`	Defines styles for painting sectors + quickly. The form of each line is + "Mode\|Name\|Upper\|Middle\|Lower\|Floor\|Ceiling". + e.g. `0x19\|Quarry\|SP_ROCK1\|SP_ROCK1\|SP_ROCK1\|RROCK09\|F_SKY1` + The mode is a bit significant number where the bits + have the following meaning: + + Bit 0 - Paint textures on the sidedefs facing + into this sector + Bit 1 - Paint textures on the sidedefs facing out + of this sector + Bit 2 - Leave current lower/upper settings + Bit 3 - Set upper unpegged if an upper texture is + painted + Bit 4 - Set lower unpegged if a lower texture is + painted + + If neither bits 2, 3 or 4 are set it is assumed that + lower/upper unpegged will be cleared on painting those + textures. +
`%EMPTY_TEXTURE_NAME`	Simply defines the empty texture name + used by DOOM. This will generally just be the - + character, e.g. `%EMPTY_TEXTURE_NAME + -` +
`%NORMAL_TYPES`	Defines the values that define the + normal linedefs and sectors. The form of the single line + of data is "Id for normal linedef\|Id for normal + sector". In all current versions of Doom this is + zero, e.g. `%NORMAL_TYPES + 0\|0` +
`%LINEDEF_CHECK_DEFAULT`	Provides an optional default texture to + use when a texture is requested when checking linedefs. + If this value is defined to be the same as + EMPTY_TEXTURE_NAME then the user is prompted for a + texture to use, otherwise this texture is used instead, + e.g. `%LINEDEF_CHECK_DEFAULT + ASHWALL` + See editing for + details on the check linedef operation. +

+ +

Back to index

+ +

$Id: overview.htm,v 1.9 2000/08/13 00:35:59 dosuser Exp dosuser $

+ + -- cgit v1.2.3