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/bugs.htm | 40 ++ doc/building.htm | 90 ++++ doc/changelog.htm | 49 ++ doc/ed_ex1.png | Bin 0 -> 262 bytes doc/ed_ex2.png | Bin 0 -> 304 bytes doc/ed_ex3.png | Bin 0 -> 327 bytes doc/ed_line.png | Bin 0 -> 7837 bytes doc/ed_lninf.png | Bin 0 -> 1267 bytes doc/ed_merge.png | Bin 0 -> 10423 bytes doc/ed_multi.png | Bin 0 -> 11443 bytes doc/ed_sect.png | Bin 0 -> 10062 bytes doc/ed_step.png | Bin 0 -> 9039 bytes doc/ed_thing.png | Bin 0 -> 10467 bytes doc/ed_vert.png | Bin 0 -> 8125 bytes doc/editing.htm | 1295 ++++++++++++++++++++++++++++++++++++++++++++++++++++ doc/glossary.htm | 127 ++++++ doc/index.htm | 47 ++ doc/license.htm | 362 +++++++++++++++ doc/mainmenu.htm | 111 +++++ doc/overview.htm | 881 +++++++++++++++++++++++++++++++++++ doc/porting.htm | 1318 +++++++++++++++++++++++++++++++++++++++++++++++++++++ doc/thanks.htm | 70 +++ 22 files changed, 4390 insertions(+) create mode 100644 doc/bugs.htm create mode 100644 doc/building.htm create mode 100644 doc/changelog.htm create mode 100644 doc/ed_ex1.png create mode 100644 doc/ed_ex2.png create mode 100644 doc/ed_ex3.png create mode 100644 doc/ed_line.png create mode 100644 doc/ed_lninf.png create mode 100644 doc/ed_merge.png create mode 100644 doc/ed_multi.png create mode 100644 doc/ed_sect.png create mode 100644 doc/ed_step.png create mode 100644 doc/ed_thing.png create mode 100644 doc/ed_vert.png create mode 100644 doc/editing.htm create mode 100644 doc/glossary.htm create mode 100644 doc/index.htm create mode 100644 doc/license.htm create mode 100644 doc/mainmenu.htm create mode 100644 doc/overview.htm create mode 100644 doc/porting.htm create mode 100644 doc/thanks.htm (limited to 'doc') diff --git a/doc/bugs.htm b/doc/bugs.htm new file mode 100644 index 0000000..40dcfc0 --- /dev/null +++ b/doc/bugs.htm @@ -0,0 +1,40 @@ + + + + + +viDOOM - Free Software DOOM editor + + + + +

Bugs

+ +

If you find any additional bugs please try and send as much +information (including a surefire way of repeating the problem if +possible) here. +Include the VERSION file from the distribution with your message. +If the problem is more likely to be platform specific (e.g. a bug +in the screen or file handling) please contact the following +people:

+ + + + + + +

DJGPP/DOS

ianc@noddybox.demon.co.uk
+ Note: messages with any sort + of attachment will not be accepted.

+ +

Back to index

+ +

$Id: bugs.htm,v 1.4 2000/07/18 16:49:48 dosuser Exp dosuser $

+ + diff --git a/doc/building.htm b/doc/building.htm new file mode 100644 index 0000000..b2de7b0 --- /dev/null +++ b/doc/building.htm @@ -0,0 +1,90 @@ + + + + + +viDOOM - Free Software DOOM editor + + + + +

Building

+ +

This part of the documentation simply expands slightly +on the contents of the README in the source distribution.

+ +

Notes

+ +

Note that the viDOOM makefile expects the include +command to be honoured.

+ +

Instructions

+ +

Step 1

+ +

Edit the makefile.

+ +

Step 2

+ +

Change the following line to the name of your platform:

+ +

+
MAKEPLAT=djgpp
+

+ +

The following platforms are currently supported:

+ +

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

+ +

Step 3

+ +

If you are going to use the install script, then update the +following line:

+ +

+
INSTALLDIR=C:/viDOOM
+

+ +

so it points to the directory where you wish it to be +installed.

+ +

Step 4

+ +

Set the MKDS to the directory separator for this platform. +This is used so that the makefile can safely access +sub directories:

+ +

+
MKDS=/
+

+ +

Step 5

+ +

If you wish to build the debug version remove the comment +(hash character - #) from the start of the following line:

+ +

+
DEBUG=-DDEBUG
+

+ +

Step 6

+ +

To make viDOOM simply invoke the make program for your system. +To install viDOOM invoke the make program for your system, +telling it to build the rule install.

+ +

Back to the index

+ +

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

+ + diff --git a/doc/changelog.htm b/doc/changelog.htm new file mode 100644 index 0000000..1192579 --- /dev/null +++ b/doc/changelog.htm @@ -0,0 +1,49 @@ + + + + + +viDOOM - Free Software DOOM editor + + + + +

Changelog

+ +

Below is a list of the major features added or bugs fixed in +each release:

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

Version	Date	Changes
0.01	05/08/2000	Initial release
0.02	13/08/2000	+ Fixed bug in step creation + Added functionality to allow the selection of + overlapping objects + +

+ +

Back to index

+ +

$Id: changelog.htm,v 1.2 2000/08/13 17:26:40 dosuser Exp dosuser $

+ + diff --git a/doc/ed_ex1.png b/doc/ed_ex1.png new file mode 100644 index 0000000..503fdbc Binary files /dev/null and b/doc/ed_ex1.png differ diff --git a/doc/ed_ex2.png b/doc/ed_ex2.png new file mode 100644 index 0000000..8e4986d Binary files /dev/null and b/doc/ed_ex2.png differ diff --git a/doc/ed_ex3.png b/doc/ed_ex3.png new file mode 100644 index 0000000..aee4bc6 Binary files /dev/null and b/doc/ed_ex3.png differ diff --git a/doc/ed_line.png b/doc/ed_line.png new file mode 100644 index 0000000..a4aa32a Binary files /dev/null and b/doc/ed_line.png differ diff --git a/doc/ed_lninf.png b/doc/ed_lninf.png new file mode 100644 index 0000000..46cbc8a Binary files /dev/null and b/doc/ed_lninf.png differ diff --git a/doc/ed_merge.png b/doc/ed_merge.png new file mode 100644 index 0000000..f08707a Binary files /dev/null and b/doc/ed_merge.png differ diff --git a/doc/ed_multi.png b/doc/ed_multi.png new file mode 100644 index 0000000..a1bbf59 Binary files /dev/null and b/doc/ed_multi.png differ diff --git a/doc/ed_sect.png b/doc/ed_sect.png new file mode 100644 index 0000000..3bd3fad Binary files /dev/null and b/doc/ed_sect.png differ diff --git a/doc/ed_step.png b/doc/ed_step.png new file mode 100644 index 0000000..ab4140f Binary files /dev/null and b/doc/ed_step.png differ diff --git a/doc/ed_thing.png b/doc/ed_thing.png new file mode 100644 index 0000000..d063772 Binary files /dev/null and b/doc/ed_thing.png differ diff --git a/doc/ed_vert.png b/doc/ed_vert.png new file mode 100644 index 0000000..5ab35dc Binary files /dev/null and b/doc/ed_vert.png differ diff --git a/doc/editing.htm b/doc/editing.htm new file mode 100644 index 0000000..ed60043 --- /dev/null +++ b/doc/editing.htm @@ -0,0 +1,1295 @@ + + + + + +viDOOM - Free Software DOOM editor + + + + +

Editing

+ +

Index

+ +

This page is split up into the following +sections:

+ +

The Basics
Basic Mouse Operation
General Key Commands
Sector Edit Mode
- Display
- Extra Keys
- Insertion
- Deletion
- Popup Menu
+
Linedef Edit Mode
- Display
- Extra Keys
- Insertion
- Deletion
- Popup Menu
- Sidedef Menu
- Stair creation
+
Thing Edit Mode
- Display
- Extra Keys
- Insertion
- Deletion
- Popup Menu
+
Vertex Edit Mode
- Display
- Extra Keys
- Insertion
- Deletion
- Popup Menu
+
Multiple Edit Mode
- Display
- Operation
+
Merging Maps

+ +

The Basics

+ +

Once you start editing in viDOOM you should be +greeted by a screen similar to the following (no prizes for +guessing the map number):

+ +

At the top of the screen is a title bar which shows the +following information, going from left to right:

+ +

The edit mode. This is either 'Sector', 'Linedef', + 'Thing' or 'Vertex'.
The position of the mouse pointer in the map.
The current scale
Whether movements are locked to the current grid scale.
The grid scale. The first number indicate the grid scale + that objects are snapped to. The second number indicates + how big the graphical grid displayed is (the blue lines + in the picture above). This second number changes + automatically as the display is zoomed in and out.
Below this is a line where specific edit modes can show + extra information.

+ +

The main central part of the screen is made up the map being +edited.

+ +

At the bottom (and sometimes the middle right) of the screen +are information boxes that display details of the object the +mouse pointer is currently over. The size and information in +these boxes changes with the edit mode.

+ +

Basic Mouse Operation

+ +

The mouse acts in exactly the same way, independent of the +mode. Simply left click over an object to select it. If the +control key is pressed while selecting the object the object is +selected in addition to any others currently selected.

+ +

If the shift key is pressed then while the left button is held +down a selection rectangle can be dragged out. Any objects within +this box once the button is released will be selected (DOOM map +designers note - in this instance objects are selected in order +from the lowest numbered object up). If the control key is +pressed along with the shift key then the objects in the box are +selected in addition to any others currently selected.

+ +

On pressing the right button a pop-up menu is displayed. If no +objects are currently selected then the menu just has the insert +option. If objects are selected when pressing the right mouse +button (please see the overview +to see how the right button can also be made to select objects +the pointer is currently over) then a menu is shown with options +specific to each edit mode.

+ +

If the left mouse button is pressed without the control key +and the pointer is not over any object then the current selection +is cleared.

+ +

If the mouse has a middle button then this can be used to move +objects once they have been selected. This basically a short cut +for pressing the right button then selecting the 'Move' option.

+ +

General Key Commands

+ +

There are a number of key commands that are common to all edit +modes in viDOOM. These are as follows:

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

F1	General Help (key commands and mouse + usage).
F2	Help specific to the current edit mode
Escape	Finish Editing
Cursor Keys	Move the map display
Shift + Cursor Keys	Move the map display quickly
Ctrl + Cursor Keys	Move the map by one pixel (i.e. by + whatever value the scale is currently set to).
Page Up/Down	Zoom in/out
Q/W	Alert the grid lock scale
G	Switch grid lines on/off
X	Switch grid snapping on/off
Tab/Shift Tab	Go to next/previous edit mode
V	VERTEX edit mode
L	LINEDEF edit + mode
S	SECTOR edit mode
T	THING edit mode
C	MULTI edit mode
F9	Deselect all objects
Shift + F9	Invert current selection
F10	Select all objects
Shift + F10	Select all objects with a specific type + (not applicable to VERTEX objects).
Ctrl + F10	Select one object at the current + position. This is mainly useful for THING and VERTEX + where it may not be possible to select objects that are + overlaid one another. When pressed if there are more + than one object at the current position a list will be + displayed with object numbers (and perhaps some extra + identifying information). Selecting one of the objects + from this list will select that object, whereas + cancelling the list leaves the current selection as is. + + Note that it may not be possible to see the selected object in it's + selected colours if it is not on top of the stack of overlapping + objects. + + + Also bear in mind, that though viDOOM can be tricked into overlapping + sectors, and these can be picked using this method, a DOOM level + should never have overlapping sectors. Unless you want the + Cyberdemon to come and take you away in the night. +
Alt + F10	As above, but any selected object is + selected in addition to the objects currently selected.
F11/Shift + F11	Locate the next or previous selected + object and display it in the centre of the screen.
Delete	Delete the selected objects ^{^{Note + 1}}
Insert	Insert a new object
F3	Merge a map. See the map FL section for details.
F4	Move selected objects
F5	Rotate selected objects ^{^{Note 2}}
[	Rotate selected objects 5° to the left ^{^{Note + 2}}
]	Rotate selected objects 5° to the right + ^{^{Note 2}}
F6	Scale selected objects ^{^{Note 2}}
{	Scale selected objects by 90% ^{^{Note + 2}}
}	Scale selected objects by 110% ^{^{Note + 2}}
F7	Set tag number for this object (only + applicable to SECTOR and LINEDEF objects).
Shift + F7	Select objects with a specific tag + number (only applicable to SECTOR and LINEDEF objects).
F8	Locate a certain object and display in + the centre of the screen
Shift + F8	Locate a certain object, display in the + centre of the screen and select it.
R	Redraw the map display. Handy for + refreshing selected objects in SECTOR mode.

+ +

Note 1: In viDOOM it is not permissible to +delete objects that are still in use by other objects, i.e. it is +impossible to delete a vertex that is still used as one of the +anchor points for a linedef - the linedef must be deleted first.

+ +

Note 2: When scaling or rotating multiple +objects the objects are rotated/scaled around the centre of the +imaginary box enclosing all the selected objects. Also grid +locking is not honoured in this mode.

+ +

Sector Edit Mode

+ +

For a basic description of a SECTOR see the glossary.

+ +

Display in Sector Mode

+ +

When in sector mode the display will look like this:

+ +

When in this mode sectors are drawn in red, vertexes are not +shown and things are drawn as a cross just to indicate their +position.

+ +

At the bottom of the screen is a box which shows the details of +the sector the pointer is currently over.

+ +

Also note that if the tag highlighting mode is enabled any +linedefs that have a tag number matching the one for the sector +the pointer is over will be drawn in white. Note that the +highlighted linedef will not appear if is in a sector that's +selected and highlighted.

+ +

Extra Keys in Sector Mode

+ +

The following extra keys can be used while in sector mode. +Keys that work on selected sectors will temporarily select the +sector the pointer is over if no sectors are selected.

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

H	Toggle the tag highlighting mode on an off. See the display section for an example + of what this does.
M	Change sector move mode. See overview for details.
, (comma)	Decrease selected sectors floor height + by 8
. (period)	Increase selected sectors floor height + by 8
<	Decrease selected sectors ceiling height + by 8
>	Increase selected sectors ceiling height + by 8
-	Decrease selected sectors lighting level + by 16
+	Increase selected sectors lighting level + by 16

+ +

Sector Insertion

+ +

When you insert a sector a popup menu is displayed where you +can select a type of sector to create.

+ + + + + + + + + + +

Create unbound sector

This will create a sector that is + unbound to any linedefs/sidedefs. It will have a normal + type as defined in the config file, a tag + of zero and a floor height, ceiling height and light + level as defined in the config file. + The floor and ceiling flats will be set to the empty texture name. + After it's creation the sector number will be displayed + onscreen.

Note that no further editing of the sector + can take place until some sidedefs/linedefs have been + manually bound to the sector, as the sector cannot be + visibly selected until they have.

Create polygon

On selecting this you will be asked for + the number of sides to the polygon (3-64). After entering + this a cross hair will be displayed. Press the left mouse + button when the cross hair is over the point where you + want the centre of the sector. Then the sector will be + drawn and you can drag it into shape (defining it's size + and rotation) using the mouse. Note that when defining + the centre and size/rotation that grid snapping can be + toggled on/off and the usual zoom in/out and map + positioning cursor keys are active.

You will be asked + then for the following information:

A class + and type + of linedef (e.g. scrolling walls, normal, + switches) out of those defined in the config + file.
The new sectors floor height, ceiling height and + light level. If the sector is being defined + inside another sector that sectors floor, ceiling + and light level will already be in the dialog + when it appears. Otherwise the default + values will be used.
A further linedef type that defines the linedef's + flags, as defined in the config file.
The style in which the sector should be painted + as defined in the config file.
If the sector is being defined within another + sector you will be asked if you wish make the + right sidedef point outwards from the new sector.

+ +

Sector Deletion

+ +

It is not possible to directly delete a sector in viDOOM as it +religiously enforces the fact that objects cannot be deleted if +other objects are still bound to them. And once all the linedefs +bound to a sector have been deleted, the sector is no longer +selectable! However, when saving, any sectors that have no +bounding linedefs will be automatically deleted.

+ +

Sector Popup Menu

+ +

On selecting sectors and pressing the right mouse button to +get the sector popup menu the following options will be +presented:

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

Change floor height	Change the height of the floor of the + selected sectors.
Change ceiling height	Change the height of the ceiling of the + selected sectors.
Change light level	Alter the light level of the sectors.
Change tag	Alter the tag value of the sectors.
Change floor	Shows a picklist of the flats from which + the floor texture can be selected.
Change ceiling	Shows a picklist of the flats from which + the ceiling texture can be selected.
Change type	Changes the sector type. The classes and their sector types are + defined in the config file.
Paint sector in style	Paints the sector using the textures + described as being a style in the config file.
Move	Move the selected sectors.
Delete	Delete the selected sectors. This just + always shows a reminder that empty sectors will be + deleted when the map is saved.

+ +

Linedef Edit Mode

+ +

For a basic description of a LINEDEF see the glossary.

+ +

Display in Linedef Mode

+ +

When in linedef mode the display will look like this:

+ +

When in this mode linedefs are just drawn as grey lines with a +normal indicating which side is the 'right' side of the linedef. +Vertexes are not shown and things are drawn as a cross just to +indicate their position..

+ +

At the bottom of the screen are three boxes which shows the +details of the linedef the pointer is currently over, and any +associated right and left sidedef. Note that in the screenshot +above the type of linedef is show as the hex number and the class of linedef. This +can be altered in the config file so +that the linedef type is show as as it's hex number and the name +defined for the linedef type +in the config file if you are using a display with an higher +resolution. An example of the alterative info for the same +linedef is shown below.

+ +

Also note this if the tag highlight mode is on then if the +linedef the pointer is over has a non-zero tag number any sectors +with the same tag number are highlighted in white. E.g. in the +display above the pointer is over a linedef set to teleport, the +tag indicating which sector the teleported object will arrive in. +The sector above and to the right of the line has this tag and is +highlighted. Note that only linedefs not already selected in the +highlighted sector will be highlighted.

+ +

Extra Keys in Linedef Mode

+ +

The following extra keys can be used while in linedef mode.

+ + + + + + + + + + +

Toggle the tag highlighting mode on an + off. See the display + section for an example of what this does.

F12

Check the currently selected linedefs. + It checks and prompts for the following things:

Removal of lower textures on 1-sided linedefs.
+ This check can be disabled in the config + file.
Removal of upper textures on 1-sided linedefs.
+ This check can be disabled in the config + file.
Addition of missing middle textures on 1-sided + linedefs.
+ This check can be disabled in the config + file.
Removal of all textures on 2-sided linedefs where + both sides of the linedef are in the same sector.
+ This check can be disabled in the config + file.
Removal of middle textures on 2-sided linedefs.
+ This check can be disabled in the config + file.
Addition of lower textures on 2-sided linedefs + where the floor heights are different on either + side. In this test the lower texture will be + removed if the floor heights are not different.
+ This check can be disabled in the config + file.
Addition of upper textures on 2-sided linedefs + where the ceiling heights are different on either + side. In this test the upper texture will be + removed if the ceiling heights are not different.
+ This check can be disabled in the config + file.

Note that whenever textures are to be added viDOOM + will display the picklist to request what texture to + paint, unless the LINEDEF_CHECK_DEFAULT section in the config file + is set up.

Important Note: That it may not be + advisable to use this on all linedefs if there are lots + of lifts in the level. viDOOM (due to wanting to remain + completely config file driven for types) is unable to + realise that some textures that look like they shouldn't + be there will come into play when the lift is activated. + This may be changed in the future so that sidedefs that + are pointing into a sector tagged to a linedef of a + specified class are not checked.

+ +

Linedef Insertion

+ +

When inserting a new linedef you will be asked for 2 vertices +to link together. You will then be asked for the linedef type +(from the list defined in the config file) and the +middle texture for it. Note that the linedef is created bound to +sector zero. This must be manually changed if it is wrong.

+ +

Linedef Deletion

+ +

Linedefs can be safely deleted from the map at any time.

+ +

Linedef Popup Menu

+ +

On selecting things and pressing the right mouse button to get +the thing popup menu the following options will be presented:

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

Change linedef flags	Allows the flags of the selected + linedefs to be changed. On selecting this a dialog will + appear allowing any of flags (as defined by the config file) to to + toggled on or off.
Change linedef type	Change the type of the selected + linedefs. On selecting this a list will appear so a class + of linedef can be selected (classes are defined in the config file). + Once the class has been selected the a picklist will + appear from which a type of linedef from that class can + be selected. The types are also defined in the config file.
Swap sides	Swaps the sides of the linedef, so that + the linedef points in the other directions. Note that the + sidedefs are re-arranged so that the texturing and + sector numbers on the sides of the linedef are not + switched.
Split line	Splits the selected linedefs in the + middle.
Select trail from this + linedef	Selects a trail from the last selected + linedef, staying within the same sector as the one on the + linedefs right sidedef, until the starting point is found + again or there are no more linedefs in the same + direction. Note that this behaves differently if the + starting point is a 2-sided line wholly within one sector + - only 2-sided linedefs wholly within the sector too + connected from this one are selected. +
Join linedefs with steps	Allows two selected linedefs to be + joined with steps. See the Stair + creation section for details.
Right Sidedef	This will display a sub menu for operation for the + right sidedef. See the Sidedef + menu for details.
Left Sidedef	This will display a sub menu for operation for the + left sidedef. See the Sidedef + menu for details.
Change tag	Change the tag number for the selected + linedefs.
Move	Move the selected linedefs.
Delete	Delete the selected linedefs.

+ +

Sidedef Menu

+ +

On selecting the Right sidedef or Left +sidedef options above the following options can be +chosen.

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

Change upper texture	Alter the upper texture on the selected + sidedef.
Change middle texture	Alter the middle texture on the selected + sidedef.
Change lower texture	Alter the lower texture on the selected + sidedef.
Change texture offset	Sets the texture offset for the selected + sidedef.
Adjust texture offset	Adjusts the texture offset for the + selected sidedefs. ie. Entering '10' for X and '-10' for + Y will add 10 to all the X offsets and subtract 10 from + all the Y offsets.
Change sector	Alters the sector number the sidedef is + linked with.
Align textures	Aligns the linedefs textures in the + selected sidedef. Note that when doing this the widest + texture out of the upper, middle and lower textures are + used to calculate the offsets. Also note that the + linedefs are aligned in the order they were selected, so + ensure you selected them in the order they appear. Remember + that if doing the same set of linedefs then the order + should be reversed when doing the left sidedef over the + right sidedef. +

+ +

Stair creation

+ +

This joins the two selected linedefs with steps. Before +starting this option a couple of caveats should be noted:

+ +

Lines must be non-zero in length and not share any + vertices.
viDOOM assumes that the steps join up the left sidedef of + the linedefs together. This will generally be the case + anyway, and if it isn't remember to Swap sides + on the linedefs as required before starting (the sides + can be swapped back once the steps have been defined).
If the linedefs already have a left sidedef, this will be + deleted in preference for the new one facing onto the new + sectors.
Not too much error checking goes on. If you do define the + most bizarre looking steps you've never seen on an + automap before, there is a fair chance they won't work + when you play them.
If the steps pass through a sector, it must be the same + sector.

+ +

i.e. the following two examples are OK, L1 and L2 can be +joined with stairs:

+ +

But the following example, where stairs would cross both +sectors S3 and S4 is not allowed:

+ +

Having got the excuses over with we can now go onto the +process involved with creating the steps. On selecting this option +you will be presented with a display like the following:

+ +

As can be seen the steps have been drawn and their are a +couple of help boxes displayed. The box in the lower left of the +screen shows the following information:

+ +

No of steps
The difference in floor height between each step
The difference in ceiling height between each step
The step drawing mode (Straight or Curve + mode).
Which side is being moved when in Curve + mode.

+ +

On the left is a box giving a quick help on the following +keys:

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

+	Increase the number of steps in the + staircase (maximum 128)
-	Decrease the number of steps in the + staircase (minimum 1)
C	Change between Straight + and Curve drawing mode. In straight mode + straight lines are drawn between the linked vertices on + the two linedefs. In curve mode a curve is defined + between the two points by moving the pointer.
S	Swaps between the two walls when + defining the curve of the walls in curve + mode.
R	Swap which vertices are paired up from + the two linedefs. For instance in the example above + switching the vertices would give the stairs a butterfly + shape rather than corridor seen above. + Obviously, the butterfly effect is not what is wanted...

+ +

After moving the stairs to the position you want you can press +ESC to cancel the process or press a mouse button to lock the +stairs in position and carry on with the creation.

+ +

At this point you will be asked if the ceiling should also be +stepped. Selecting No means that the ceiling +will stay at a constant height (the highest ceiling height out of +the two linedef's sectors), otherwise the ceiling will be stepped +accordingly.

+ +

Now the steps are created. Note that in the created steps the +pegging modes defined for the sector style the stairs will be +painted in is ignored and pegging modes and Y texture offsets +will be set appropriately to line up textures on the sides of the +steps.

+ +

Thing Edit Mode

+ +

For a basic description of a THING see the glossary.

+ +

Display in Thing Mode

+ +

When in thing mode the display will look like this:

+ +

When in this mode linedefs are just drawn as grey lines, +vertexes are not shown and things are drawn as a circle +(indicating their size within the game - like the Spider +Mastermind above) with an arrow indicating their direction. Note +different classes of things are drawn in different colours (these +colour to class pairing are defined in the config file).

+ +

At the bottom of the screen is a box which shows the details of +the thing the pointer is currently over.

+ +

Extra Keys in Thing Mode

+ +

There are no extra keys in thing edit mode.

+ +

Thing Insertion

+ +

When inserting a new thing into the map, the thing will be +inserted at the current pointer position using the values (type, +angle and flags) used when a thing was last edited. e.g.

+ +

Insert a new thing.
Select the new thing and change it's type to be a + Cyberdemon (see the Popup Menu + for how to do this).
All newly inserted things will now be Cyberdemons, until + a further edit is made.

+ +

Thing Deletion

+ +

Things can be safely deleted from the map at any time.

+ +

Thing Popup Menu

+ +

On selecting things and pressing the right mouse button to get +the thing popup menu the following options will be presented:

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

Change type	Change the type of the selected things. + On selecting this a list will appear so a class of thing + can be selected (classes are defined in the config file). Once + the class has been selected the a picklist will appear + from which a type of thing from that class can be + selected. The types are also defined in the config file.
Change angle	Allows the angle of the selected things + to be changed. On selecting this a dialog will appear + allowing any of 8 major compass points to be selected.
Change flags	Allows the flags of the selected things + to be changed. On selecting this a dialog will appear + allowing any of flags (as defined by the config file) to to + toggled on or off.
Snap selected things	Snaps the selected things to the current + grid.
Move	Move the selected things. Follow the + on-screen prompts for details on how to move the things + or cancel the operation.
Delete	Delete the selected things.

+ +

Vertex Edit Mode

+ +

For a basic description of a VERTEX see the glossary.

+ +

Display in Vertex Mode

+ +

When in vertex mode the display will look like this:

+ +

When in this mode linedefs are drawn as grey arrows, the arrow +direction corresponding to direction of the linedef - i.e. the +right side of the linedef is on the right side of the arrow. +Vertices are displayed as white points with a grey selection box +around them.

+ +

At the bottom of the Cyber demons is a box which shows the details of +the vertex the pointer is currently over.

+ +

Extra Keys in Vertex Mode

+ +

The following extra keys can be used while in linedef mode.

+ + + + + + +

F12	Goes through all the vertices and delete + ones that are not bound to a linedef.

+ +

Vertex Insertion

+ +

Inserting a vertex simply inserts a new vertex unbound to any +linedefs at the pointer location.

+ +

Vertex Deletion

+ +

Vertices can only be deleted if they are not bound to any +linedefs. Linedefs must be deleted +before you can delete the vertex.

+ +

Vertex Popup Menu

+ +

On selecting vertices and pressing the right mouse button to +get the vertex popup menu the following options will be +presented:

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

Chain selected vertices	Selecting this object will create + linedefs linking the currently selected vertices. Note + that the linedefs will be created such the the first + selected vertex is connected to the vertex selected, the + vertex selected second to the vertex selected third and + so on. On selecting this option you will be first + prompted to selected a class and type of linedef + (e.g. scrolling walls, normal, switches) out of those + defined in the config file. Following this you will be + asked for a further linedef type that defines the + linedef's flags, as defined in the config file. + If the selected linedef type is one sided and the config file + options are set accordingly a middle texture for the + linedefs will be requested. After this you will be asked + if you wish to connect the last vertex to the first one + and the linedefs will be created and any textures aligned + on them. + Tip: One thing this option is very + useful for is creating pillars and the such like inside + sectors. Insert new vertexes (with the insert select + option in the config file enabled) in the shape you want + in an anti-clockwise direction. + Then select this option and a one-sided linedef type and + the result will be a column in the room. +
Chain selected vertices + into a sector	Selecting this object will create + linedefs linking the currently selected vertices and bind + the linedefs to a newly created sector. Note that the + linedefs will be created such the the first selected + vertex is connected to the vertex selected, the vertex + selected second to the vertex selected third and so on. + It is important for this option to operate as described + below that the vertices are selected in a clockwise + direction. You will be asked then for the following + information: + + A class + and type + of linedef (e.g. scrolling walls, normal, + switches) out of those defined in the config + file. + The new sectors floor height, ceiling height and + light level. + A further linedef type that defines the linedef's + flags, as defined in the config file. + The style in which the sector should be painted + as defined in the config file. + If the sector is being defined within another + sector you will be asked if you wish make the + right sidedef point outwards from the sector. + This is useful as things like teleport linedefs + only work if you cross from the right side to the + left side of the linedef. For this part to work + as described the vertices must have been selected + in a clockwiseorder. + + Tip: If you select vertices that are + bound to linedefs in another sector, once the creation of + the sector has been completed viDOOM will ask you if you + want to merge the new linedef from the new sector with + the old one. +
Merge selected vertices	The vertices selected second, third and + so on are deleted and all references to those vertices in + linedefs changed to the be the first selected vertex. + After doing this viDOOM will see if any linedefs are now + using the same vertex pair to define their position and + you can elect to merge these.
Snap selected vertices	Snaps the selected vertices to the + current grid.
Move	Move the selected vertices. Follow the + on-screen prompts for details on how to move the vertices + or cancel the operation.
Delete	Delete the selected vertices.

+ +

Multi Edit Mode

+ +

Display

+ +

When in multi mode the display will look like this:

+ +

Things are drawn as a circle (indicating their size within the +game) with an arrow indicating their direction. Note different +classes of things are drawn in different colours (these colour to +class pairing are defined in the config file)

+ +

At the bottom of the vertexes is a box which shows what object +type (vertex or thing) the pointer is currently over and it's +number.

+ +

Operation

+ +

Multi selection mode is given just as a way of manipulating +things and vertexes, allowing them to be moved, rotated and +scaled in unison. Note that linedefs and sectors are not +selectable as these are inherently moved just by moving the +vertices.

+ +

All keys are honoured in multi selection mode, but keys for +insertion and deletion are ignored. Also the locate object number +keys (F8 and Shift + F8) are ignored.

+ +

Merging Maps

+ +

Pressing F3 in any edit mode will allow a different map to be +merged in with the currently edited map.

+ +

First you will be asked if you wish to temporarily load a PWAD +and load the first map from it. If you select Yes +then you will be prompted for a PWAD file to read. If you select No +you will be asked for a level to load from the currently loaded +WADs.

+ +

Tip: The idea of this question is that you +can save PWAD files with a structure you wish to re-use in +multiple maps as the first map. Any linedefs in this map that +have a left sidedef bound to sector number -1 will have the +sector number reset to the sector in which the merged structure +has been placed. Note that if you do insert structures this way +it will generally be required to check the sidedefs to make sure +they have all their necessary textures and remember that the +structure will have it's original sector properties (floor, +ceiling and light levels).

+ +

After choosing the map to merge in, a vector display +representing the linedefs from the map that can be moved around +the screen with the mouse is displayed as shown in the screen +below.

+ +

On the bottom left is a box giving a quick help on the +following keys:

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

, (comma)	Rotate the map 1° to the left.
. (period)	Rotate the map 1° to the right.
<	Rotate the map 10° to the left.
>	Rotate the map 10° to the right.

+ +

Pressing ESC will cancel the operation while pressing a mouse +button will place the map where it currently is.

+ +

If the merged map is assumed to be a structure (i.e. it has +left sidedefs whose sector fields are set to -1) you are then +asked whether you wish to adjust the floor heights. If you do +select to adjust them then the sector that is in the middle of +the merged in WAD has it's floor height taken. The floors and +ceilings are adjusted in the new sectors so that the lowest floor +is at the same height as the surrounding floor, but the +difference in heights between the new sectors themselves are +maintained. After this you are asked whether to adjust the +ceiling heights. If you do the ceiling height of the same sector +is taken and the new sector's ceilings adjusted to match the +surrounding ceiling (note that ceilings will not be moved if +moving them places them lower than the floor).

+ +

You will then be asked whether tags within the map should stay +as they are or be adjusted so that they are different from tags +used in the map being edited. After this the map will be inserted +and then a notice displayed showing by how much the various +objects in the merged map where adjusted.

+ +

Back to index

+ +

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

+ + diff --git a/doc/glossary.htm b/doc/glossary.htm new file mode 100644 index 0000000..ef5912a --- /dev/null +++ b/doc/glossary.htm @@ -0,0 +1,127 @@ + + + + + +viDOOM - Free Software DOOM editor + + + + +

Glossary

+ +

It is assumed that some knowledge of DOOM is known by the +reader, but in case here are some general terms that are used in +the documentation.

+ +

WAD

+ +

A WAD file is the name given to the files used to define the +graphics, sound, music and maps that make up a game of DOOM. WAD +files are split into two different types, IWAD +and PWAD files.

+ +

IWAD

+ +

An IWAD file is is the 'Internal WAD' file. The IWAD file is +the main WAD file as supplied by id Software. +Note that only id Software are meant to produce IWAD files.

+ +

PWAD

+ +

An PWAD file is is the 'Patch WAD' file. This WAD file is read +in by the game after the IWAD file, and an entries in it replace +entries defined in the IWAD file. So for instance a PWAD file +that has an entry for the first MAP will mean +that DOOM will read the first map from the PWAD file, rather than +it's own IWAD file.

+ +

Hmmmm.... Sure I could have explained that better.

+ +

MAP

+ +

A map is taken to mean a DOOM level. Note there is two naming +conventions for maps, ExMy +(where x is the episode number, and y the map +number in that episode) used in DOOM and Ultimate DOOM, and MAPnn +(where nn is a number between 01 and 32) used in DOOM 2 +and Final Doom.

+ +

A map is made up of a number of different elements, namely sectors, linedefs, sidedefs, things and vertexes. Following are some (very) basic +definitions for these things, but you would be better reading the +Unofficial DOOM specs for more +accurate definitions.

+ +

MAPs generated in viDOOM must be built with a Node +Builder before they can be used in DOOM.

+ +

VERTEX

+ +

A vertex is simply an X,Y co-ordinate in the DOOM world.

+ +

THING

+ +

Things are all the different objects on the DOOM map that are +not the actual walls and doors. All the monsters, weapons, ammo, +non-wall based scenery and even your starting point and teleport +locations are all counted as THINGS in DOOM.

+ +

LINEDEF

+ +

A LINEDEF is a line that connects two vertexes. +A LINEDEF at it's most basic is used to make up the walls that +make up the DOOM levels. A LINEDEF must always have a +right SIDEDEF associated with it. 2 sided +LINEDEFS will also have a left SIDEDEF associated with it.

+ +

In addition special types of LINEDEF can be used so that when +the player crosses or activates them actions happen in the DOOM +world - lighting changes, teleportation happens, doors open, +levels are exited and so on.

+ +

SIDEDEF

+ +

A SIDEDEF is basically used to describe the textures +that are painted upon a LINEDEF.

+ +

SECTOR

+ +

Though technically incorrect, it is simplest to picture a +SECTOR as an object enclosed by LINEDEFS. +A sector is used to define the floor and ceiling heights and flats used to draw the floor and ceiling, in +addition to the lighting for that area.

+ +

TEXTURE

+ +

A texture is the graphics used to paint the walls in DOOM.

+ +

FLAT

+ +

A flat is the graphics used to paint the floors and ceiling in +DOOM.

+ +

Node Builder

+ +

Does some of the nastier work of level building by creating +the extra information over and above the parts mentioned in MAPS so that DOOM can actually understand the +level data enough to play it.

+ +

BSP is perhaps the best known of +these, and the one that was used all through viDOOM's +development.

+ +

Back to index

+ +

$Id: glossary.htm,v 1.2 2000/07/18 16:49:48 dosuser Exp dosuser $

+ + diff --git a/doc/index.htm b/doc/index.htm new file mode 100644 index 0000000..e122330 --- /dev/null +++ b/doc/index.htm @@ -0,0 +1,47 @@ + + + + + +viDOOM - Free Software DOOM editor + + + + +

viDOOM 0.02

+ +

"... but what I talk about is DOOM, +because in the end, DOOM is all that counts."
+The Dark Half - Stephen King

+ +

viDOOM is released as free software under the +GNU General License. See licence for +details.

+ +

Index

+ +

Acknowledgements and thanks
Simple glossary
Overview (Configuration, etc)
Main menu
Editing
Porting
Bug Reports
Building (only needs to be + read for the source distribution)
Changelog

+ +

viDOOM home +page

+ +

$Id: index.htm,v 1.6 2000/07/24 16:31:58 dosuser Exp +dosuser $

+ + diff --git a/doc/license.htm b/doc/license.htm new file mode 100644 index 0000000..d07b0b8 --- /dev/null +++ b/doc/license.htm @@ -0,0 +1,362 @@ + + + + + +viDOOM - Free Software DOOM editor + + + + +

+		    GNU GENERAL PUBLIC LICENSE
+		       Version 2, June 1991
+
+ Copyright (C) 1989, 1991 Free Software Foundation, Inc.
+                       59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+			    Preamble
+
+  The licenses for most software are designed to take away your
+freedom to share and change it.  By contrast, the GNU General Public
+License is intended to guarantee your freedom to share and change free
+software--to make sure the software is free for all its users.  This
+General Public License applies to most of the Free Software
+Foundation's software and to any other program whose authors commit to
+using it.  (Some other Free Software Foundation software is covered by
+the GNU Library General Public License instead.)  You can apply it to
+your programs, too.
+
+  When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+this service if you wish), that you receive source code or can get it
+if you want it, that you can change the software or use pieces of it
+in new free programs; and that you know you can do these things.
+
+  To protect your rights, we need to make restrictions that forbid
+anyone to deny you these rights or to ask you to surrender the rights.
+These restrictions translate to certain responsibilities for you if you
+distribute copies of the software, or if you modify it.
+
+  For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must give the recipients all the rights that
+you have.  You must make sure that they, too, receive or can get the
+source code.  And you must show them these terms so they know their
+rights.
+
+  We protect your rights with two steps: (1) copyright the software, and
+(2) offer you this license which gives you legal permission to copy,
+distribute and/or modify the software.
+
+  Also, for each author's protection and ours, we want to make certain
+that everyone understands that there is no warranty for this free
+software.  If the software is modified by someone else and passed on, we
+want its recipients to know that what they have is not the original, so
+that any problems introduced by others will not reflect on the original
+authors' reputations.
+
+  Finally, any free program is threatened constantly by software
+patents.  We wish to avoid the danger that redistributors of a free
+program will individually obtain patent licenses, in effect making the
+program proprietary.  To prevent this, we have made it clear that any
+patent must be licensed for everyone's free use or not licensed at all.
+
+  The precise terms and conditions for copying, distribution and
+modification follow.
+
+		    GNU GENERAL PUBLIC LICENSE
+   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+  0. This License applies to any program or other work which contains
+a notice placed by the copyright holder saying it may be distributed
+under the terms of this General Public License.  The "Program", below,
+refers to any such program or work, and a "work based on the Program"
+means either the Program or any derivative work under copyright law:
+that is to say, a work containing the Program or a portion of it,
+either verbatim or with modifications and/or translated into another
+language.  (Hereinafter, translation is included without limitation in
+the term "modification".)  Each licensee is addressed as "you".
+
+Activities other than copying, distribution and modification are not
+covered by this License; they are outside its scope.  The act of
+running the Program is not restricted, and the output from the Program
+is covered only if its contents constitute a work based on the
+Program (independent of having been made by running the Program).
+Whether that is true depends on what the Program does.
+
+  1. You may copy and distribute verbatim copies of the Program's
+source code as you receive it, in any medium, provided that you
+conspicuously and appropriately publish on each copy an appropriate
+copyright notice and disclaimer of warranty; keep intact all the
+notices that refer to this License and to the absence of any warranty;
+and give any other recipients of the Program a copy of this License
+along with the Program.
+
+You may charge a fee for the physical act of transferring a copy, and
+you may at your option offer warranty protection in exchange for a fee.
+
+  2. You may modify your copy or copies of the Program or any portion
+of it, thus forming a work based on the Program, and copy and
+distribute such modifications or work under the terms of Section 1
+above, provided that you also meet all of these conditions:
+
+    a) You must cause the modified files to carry prominent notices
+    stating that you changed the files and the date of any change.
+
+    b) You must cause any work that you distribute or publish, that in
+    whole or in part contains or is derived from the Program or any
+    part thereof, to be licensed as a whole at no charge to all third
+    parties under the terms of this License.
+
+    c) If the modified program normally reads commands interactively
+    when run, you must cause it, when started running for such
+    interactive use in the most ordinary way, to print or display an
+    announcement including an appropriate copyright notice and a
+    notice that there is no warranty (or else, saying that you provide
+    a warranty) and that users may redistribute the program under
+    these conditions, and telling the user how to view a copy of this
+    License.  (Exception: if the Program itself is interactive but
+    does not normally print such an announcement, your work based on
+    the Program is not required to print an announcement.)
+
+These requirements apply to the modified work as a whole.  If
+identifiable sections of that work are not derived from the Program,
+and can be reasonably considered independent and separate works in
+themselves, then this License, and its terms, do not apply to those
+sections when you distribute them as separate works.  But when you
+distribute the same sections as part of a whole which is a work based
+on the Program, the distribution of the whole must be on the terms of
+this License, whose permissions for other licensees extend to the
+entire whole, and thus to each and every part regardless of who wrote it.
+
+Thus, it is not the intent of this section to claim rights or contest
+your rights to work written entirely by you; rather, the intent is to
+exercise the right to control the distribution of derivative or
+collective works based on the Program.
+
+In addition, mere aggregation of another work not based on the Program
+with the Program (or with a work based on the Program) on a volume of
+a storage or distribution medium does not bring the other work under
+the scope of this License.
+
+  3. You may copy and distribute the Program (or a work based on it,
+under Section 2) in object code or executable form under the terms of
+Sections 1 and 2 above provided that you also do one of the following:
+
+    a) Accompany it with the complete corresponding machine-readable
+    source code, which must be distributed under the terms of Sections
+    1 and 2 above on a medium customarily used for software interchange; or,
+
+    b) Accompany it with a written offer, valid for at least three
+    years, to give any third party, for a charge no more than your
+    cost of physically performing source distribution, a complete
+    machine-readable copy of the corresponding source code, to be
+    distributed under the terms of Sections 1 and 2 above on a medium
+    customarily used for software interchange; or,
+
+    c) Accompany it with the information you received as to the offer
+    to distribute corresponding source code.  (This alternative is
+    allowed only for noncommercial distribution and only if you
+    received the program in object code or executable form with such
+    an offer, in accord with Subsection b above.)
+
+The source code for a work means the preferred form of the work for
+making modifications to it.  For an executable work, complete source
+code means all the source code for all modules it contains, plus any
+associated interface definition files, plus the scripts used to
+control compilation and installation of the executable.  However, as a
+special exception, the source code distributed need not include
+anything that is normally distributed (in either source or binary
+form) with the major components (compiler, kernel, and so on) of the
+operating system on which the executable runs, unless that component
+itself accompanies the executable.
+
+If distribution of executable or object code is made by offering
+access to copy from a designated place, then offering equivalent
+access to copy the source code from the same place counts as
+distribution of the source code, even though third parties are not
+compelled to copy the source along with the object code.
+
+  4. You may not copy, modify, sublicense, or distribute the Program
+except as expressly provided under this License.  Any attempt
+otherwise to copy, modify, sublicense or distribute the Program is
+void, and will automatically terminate your rights under this License.
+However, parties who have received copies, or rights, from you under
+this License will not have their licenses terminated so long as such
+parties remain in full compliance.
+
+  5. You are not required to accept this License, since you have not
+signed it.  However, nothing else grants you permission to modify or
+distribute the Program or its derivative works.  These actions are
+prohibited by law if you do not accept this License.  Therefore, by
+modifying or distributing the Program (or any work based on the
+Program), you indicate your acceptance of this License to do so, and
+all its terms and conditions for copying, distributing or modifying
+the Program or works based on it.
+
+  6. Each time you redistribute the Program (or any work based on the
+Program), the recipient automatically receives a license from the
+original licensor to copy, distribute or modify the Program subject to
+these terms and conditions.  You may not impose any further
+restrictions on the recipients' exercise of the rights granted herein.
+You are not responsible for enforcing compliance by third parties to
+this License.
+
+  7. If, as a consequence of a court judgment or allegation of patent
+infringement or for any other reason (not limited to patent issues),
+conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License.  If you cannot
+distribute so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you
+may not distribute the Program at all.  For example, if a patent
+license would not permit royalty-free redistribution of the Program by
+all those who receive copies directly or indirectly through you, then
+the only way you could satisfy both it and this License would be to
+refrain entirely from distribution of the Program.
+
+If any portion of this section is held invalid or unenforceable under
+any particular circumstance, the balance of the section is intended to
+apply and the section as a whole is intended to apply in other
+circumstances.
+
+It is not the purpose of this section to induce you to infringe any
+patents or other property right claims or to contest validity of any
+such claims; this section has the sole purpose of protecting the
+integrity of the free software distribution system, which is
+implemented by public license practices.  Many people have made
+generous contributions to the wide range of software distributed
+through that system in reliance on consistent application of that
+system; it is up to the author/donor to decide if he or she is willing
+to distribute software through any other system and a licensee cannot
+impose that choice.
+
+This section is intended to make thoroughly clear what is believed to
+be a consequence of the rest of this License.
+
+  8. If the distribution and/or use of the Program is restricted in
+certain countries either by patents or by copyrighted interfaces, the
+original copyright holder who places the Program under this License
+may add an explicit geographical distribution limitation excluding
+those countries, so that distribution is permitted only in or among
+countries not thus excluded.  In such case, this License incorporates
+the limitation as if written in the body of this License.
+
+  9. The Free Software Foundation may publish revised and/or new versions
+of the General Public License from time to time.  Such new versions will
+be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+
+Each version is given a distinguishing version number.  If the Program
+specifies a version number of this License which applies to it and "any
+later version", you have the option of following the terms and conditions
+either of that version or of any later version published by the Free
+Software Foundation.  If the Program does not specify a version number of
+this License, you may choose any version ever published by the Free Software
+Foundation.
+
+  10. If you wish to incorporate parts of the Program into other free
+programs whose distribution conditions are different, write to the author
+to ask for permission.  For software which is copyrighted by the Free
+Software Foundation, write to the Free Software Foundation; we sometimes
+make exceptions for this.  Our decision will be guided by the two goals
+of preserving the free status of all derivatives of our free software and
+of promoting the sharing and reuse of software generally.
+
+			    NO WARRANTY
+
+  11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
+FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN
+OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
+PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
+OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS
+TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE
+PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
+REPAIR OR CORRECTION.
+
+  12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
+REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
+INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
+OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
+TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
+YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
+PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGES.
+
+		     END OF TERMS AND CONDITIONS
+
+	    How to Apply These Terms to Your New Programs
+
+  If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these terms.
+
+  To do so, attach the following notices to the program.  It is safest
+to attach them to the start of each source file to most effectively
+convey the exclusion of warranty; and each file should have at least
+the "copyright" line and a pointer to where the full notice is found.
+
+    
+    Copyright (C) 19yy  
+
+    This program is free software; you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation; either version 2 of the License, or
+    (at your option) any later version.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+
+    You should have received a copy of the GNU General Public License
+    along with this program; if not, write to the Free Software
+    Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+
+
+Also add information on how to contact you by electronic and paper mail.
+
+If the program is interactive, make it output a short notice like this
+when it starts in an interactive mode:
+
+    Gnomovision version 69, Copyright (C) 19yy name of author
+    Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
+    This is free software, and you are welcome to redistribute it
+    under certain conditions; type `show c' for details.
+
+The hypothetical commands `show w' and `show c' should show the appropriate
+parts of the General Public License.  Of course, the commands you use may
+be called something other than `show w' and `show c'; they could even be
+mouse-clicks or menu items--whatever suits your program.
+
+You should also get your employer (if you work as a programmer) or your
+school, if any, to sign a "copyright disclaimer" for the program, if
+necessary.  Here is a sample; alter the names:
+
+  Yoyodyne, Inc., hereby disclaims all copyright interest in the program
+  `Gnomovision' (which makes passes at compilers) written by James Hacker.
+
+  , 1 April 1989
+  Ty Coon, President of Vice
+
+This General Public License does not permit incorporating your program into
+proprietary programs.  If your program is a subroutine library, you may
+consider it more useful to permit linking proprietary applications with the
+library.  If this is what you want to do, use the GNU Library General
+Public License instead of this License.
+

+ + +

+ +

Back to index

+ +

$Id: license.htm,v 1.1 2000/07/13 15:05:48 dosuser Exp dosuser $

+ + diff --git a/doc/mainmenu.htm b/doc/mainmenu.htm new file mode 100644 index 0000000..e768904 --- /dev/null +++ b/doc/mainmenu.htm @@ -0,0 +1,111 @@ + + + + + +viDOOM - Free Software DOOM editor + + + + +

Main Menu

+ +

Depending on the setting in configuration +starting viDOOM you may be asked to pick the game type to edit. +Pick one of the games from the menu, or if the menu is cancelled +the default game type will +be used.

+ +

After this you will be presented with the main menu containing +the following options.

+ +

Edit The Current Level

+ +

Edit the current level. See editing +for details.

+ +

Load Level from open WADs

+ +

Selects a level to load from the open IWAD and PWAD files. +Note that the level is loaded from the most recent +WAD file opened that holds a map for the selected level. If you +already have a level open for editing and the Edit The +Current Level option has been used then confirmation +will be asked before allowing you to proceed. This warning can be +disabled in the INI file (see overview).

+ +

Save Current Level

+ +

Saves the map you are currently editing into a PWAD file. This PWAD will only +contain the map, and nothing else. So if you have loaded the map +from a PWAD that contains any other information (e.g. music, +extra sounds, graphics patches) it is not a good idea to save +over the original PWAD file. If the saved PWAD filename matches a +PWAD that is already loaded, after saving the open PWAD will be +closed and then re-opened. This could be important to note as the +saved PWAD will now be at the top of the open PWADs.

+ +

Note that the saved map must be built with a node builder before it can be played +in DOOM if the node building +section in the config file has not been set up.

+ +

Important note: While saving viDOOM will +remove any deleted objects from the map, delete any sectors that +do no have linedefs attached to them and vertices that are not in +use. This is worth remembering as objects will be +renumbered if any have been deleted so that they fit together +contiguously after saving.

+ +

Create New Empty Level

+ +

Creates a completely empty level for editing. If you already +have a level open for editing and the Edit The Current +Level option has been used then confirmation will be +asked before allowing you to proceed. This warning can be +disabled in the INI file (see overview).

+ +

Change Current Level Name

+ +

Allows the map to be assigned to a different map number. See +the glossary for some extra info +on map/level numbers.

+ +

Open PWAD file

+ +

Allows a PWAD file to be opened.

+ +

Close PWAD file

+ +

Closes one of the currently open PWAD files. Note that viDOOM +will not let you unload the IWAD +opened at startup.

+ +

Preview Level

+ +

Allows a level to be previewed without disturbing the level +currently being edited. Note that the preview is very +basic with linedefs shown as grey lines, vertexes as white pixels +and things as red blobs. While in the preview press F1 for help +on controlling the display.

+ +

About viDOOM

+ +

See who was responsible for this.

+ +

Quit

+ +

Exit viDOOM. If you have a level open for editing and the Edit +The Current Level option has been used then confirmation +will be asked before allowing you to proceed. This warning can be +disabled in the INI file (see overview).

+ +

Back to index

+ +

$Id: mainmenu.htm,v 1.6 2000/08/13 00:14:33 dosuser Exp dosuser $

+ + 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 $

+ + diff --git a/doc/porting.htm b/doc/porting.htm new file mode 100644 index 0000000..99d3cf1 --- /dev/null +++ b/doc/porting.htm @@ -0,0 +1,1318 @@ + + + + + +viDOOM - Free Software DOOM editor + + + + +

Porting viDOOM

+ +

This document is provided in case anyone wishes to port viDOOM +to a new platform. Below is an indication of what OS dependent +routines must be provided and what configuration needs to be +done. It is requested that any ports are also released as Free +Software.

+ +

Makefile configuration
INI File
Files
Main entry point
Graphics and input
Platform GUI
File interface
Memory allocation
External command execution
String functions
Installation script
Documentation

+ +

Makefile configuration

+ +

makefile

+ +

Set the variable MAKEPLAT +to the name of your platform, eg.

+ +

MAKEPLAT=OS

+ +

You will then need to create a matching file the make +sub directory called OS.cfg. Also all the OS dependent C +source should go into a sub directory defined in the following +make config file by the PLATFORM variable. See +the Files section for an overview of these +files.

+ +

make config file

+ +

The following values need to be set in the file make/OS.cfg:

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

`CC`	Set to the name of the C compiler.
`LD`	The name of the linker.
`PLATFORM`	The name of the D containing + the OS dependent C sources. The idea of defineing tdefining here, rather than using the MAKEPLAT variable defined in + the top level makefile, is so that different + configurations can share sources. i.e. An X11 port may + use the same code for all the unix platforms, but each + machine may require slightly different configuration + (library search paths for example).
`EXE_EXT`	An extension to add to the executable + name, e.g. + `EXE_EXT=.EXE`
`OBJ_EXT`	The extension used in this OS to denote + object files produced by the C compiler. Generally: + `OBJ_EXT=.o`
`LIBS`	Any extra libraries to link in with + viDOOM for the OS dependent routines.
`EXRACF`	Any extra C flags required when + compiling the sources. Use it to enable optimisation and + to include any extra include paths required by this OS.
`EXTRALF`	Any extra flags required when linking + viDOOM. Use it to enable include any extra library paths + required by this OS.
`DIRSEP`	The directory separator character for + this OS. The character must be included in quotes, e.g.`+DIRSEP="/"`
`MATHLIB`	The options required to include the + maths library when linking.
`TRACEFORM`	This variable is a printf format string + and the arguments to the format. This string is used to + provide a tracing function used to track bugs in the + editor. A simple, portable example is: + `TRACEFORM="%s:%d",__FILE__,__LINE__` It + can just be defined to an empty string if you are not + compiling the debug version. +
`EXEFLAG`	The flag to provide to the linker to + generate an executable. The flag is used in a rule + something like this: + `$(LD) $(EXTRALF) $(EXEFLAG) vidoom$(EXE_EXT) + $(ALL+VIDOOM_OBJECTS)`
`OBJFLAG`	The flag to provide to the C compiler to + generate an object file from the supplied C source. The + flag is used in a rule something like this: + `$(CC) $(EXTRACF) $(OBJFLAG) file.c`
`DEFINEFLAG`	The flag to provide to the C compiler + with pre-processor definition from the command line. The + flag is used in a rule something like this (note no space + after the DEFINEFLAG - if there is a space between the + switch and the argument put it in this variable + definition): + `$(CC) $(EXTRACF) $(OBJFLAG) $(DEFINEFLAG)MACRO=value + file.c`
`INCFLAG`	The flag to provide to the C compiler + with extra directories in which the pre-processor + searches for include files. The flag is used in a rule + something like this (note no space after the INCFLAG - if + there is a space between the switch and the argument put + it in this variable definition): + `$(CC) $(EXTRACF) $(OBJFLAG) $(INCFLAG)include_dir + file.c`
`MAKEINSTALL`	The command used to execute the install + makefile as described in the installation + script section. The command must define the + INSTALLDIR variable for the makefile and invoke the first + rule in the install makefile. For instance, using a + normal unix/GCC type make command, this would be: + `make INSTALL_DIR='$(INSTALL_DIR)' -f install` +

+ +

INI File

+ +

If your port requires or wants configuration to be set at +tun-time from the INI file, it is best to place it a +system-dependent section called the same as the OS value +you set MAKEPLAT to for this platform, +e.g.

+ +

[OS] +guimode=3D

+ +

Files

+ +

The following files are the minimum that must be provided by +the platform:

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

make/OS.cfg	The make config file. Described in the previous section.
main.c	This goes in the platform + directory and provides the startup + code for the operating system.
gfx.c	This goes in the platform + directory and provides the low level + graphics and input.
platgui.c	This goes in the platform + directory and provides the system + dependent GUI.
file.c	This goes in the platform + directory and provides the portable part of the file system interface.
mem.c	This goes in the platform + directory and provides the memory + handling.
runcmd.c	This goes in the platform + directory and provides the method for running external commands.
vstring.c	This goes in the platform + directory and provides functions for string comparisons.
install	This goes in the platform + directory and is the makefile invoked to install viDOOM.

+ +

Main entry point

+ +

main.c

+ +

The OS dependent code must provide it's own main (this is to +allow for various non-standard environments where main() is not +the standard entry point). The entry point must do any OS +dependent initialisations then invoke the following entry point +to start up viDOOM:

+ +

int viDOOM(int argv, char *argv[])

+ +

If the OS uses main() as an entry point the following example +could be enough:

+ +

int main(int argc,char *argv[])
+{
+    return (viDOOM(argc,argv));
+}

+ +

Graphics and input

+ +

gfx.c

+ +

This provides the low-level graphics access and interfaces to +keyboard and mouse. The GFX object is expected to work on a weak, +semi-event driven basis for keyboard/mouse access. The following +are the basic assumptions about the GFX interface:

+ +

A true, or hicolor, display.
A Fixed font.
Default origin is in the top left of the display, with X + positive along and Y positive down.
A buffered display. The screen contents should not change + until GFX_redraw() is called. If not honoured viDOOM + should still work up to a point, but it's use of the XOR + mode may not be apparent to the user.
Colours are represented using an int, with 8 bits each + for the red, green and blue component. The int used to + define the colour, when viewed in hex, would look like 0xRRGGBB. + Some examples are:
- 0xFF0000 - Red
- 0x00FF00 - Green
- 0x0000FF - Blue
- 0xFFFFFF - White
- 0x808080 - 50% grey
- 0x000000 - Black
+

+ +

The following types are defined and used by the GFX object :

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

typedef void *GFX_IMAGE;

This is an opaque type provided to allow + the GFX object to provide whatever is required to + reference a bitmap on the machine.

typedef struct
+    {
+    int           w;
+    int           h;
+    int           pal[256];
+    unsigned char *data;
+    } GFX_BITMAP;

This type represents the bitmap objects + that viDOOM defines. These bitmaps are converted into + GFX_IMAGE prior to use. The fields are: + + + + + + + + + + + + + + + + + + + + +

w	-	width of bitmap
h	-	height of bitmap
pal[256]	-	The palette used to define the + bitmap. Each bitmap pixel is an index into this + array of RGB values. Each entry is an integer, + that when represented in hex would define the RGB + triplet as 0xRRGGBB.
*data	-	A pointer to the data of the + bitmap. This should be accessed using pointer + arithmetic as (data+(x)+(yw))

typedef struct
+    {
+    int    type;
+    int    shift;
+    int    ctrl;
+    int    alt;
+    char   ascii;
+    int    code;
+    } GFXKey;

This defines an object for reporting key + presses. The fields are: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

type	-	The type of event. This field is + just used to line up with the event union defined + later on. Should just hold GFX_KEY_EVENT.
shift	-	TRUE if the Shift key is being + pressed.
ctrl	-	TRUE if the Control key is being + pressed.
alt	-	TRUE if the Alt key is being + pressed.
ascii	-	The ASCII code of the character + read. If the key is not an ASCII key (e.g. a + function key) this field should be zero.
code	-	Holds the code for non-ASCII + keys, e.g. GFX_F1. This field should be set to + GFX_ASCII for key presses reported through the + ascii field.

typedef struct GFXMouse
+    {
+    int    type;
+    int    shift;
+    int    ctrl;
+    int    alt;
+    int    x;
+    int    y;
+    int    b;
+    } GFXMouse;

This defines the type for reporting + mouse movements and button presses. The fields are: + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

type	-	The type of event. This field is + just used to line up with the event union defined + later on. Should just hold GFX_MOUSE_EVENT.
shift	-	TRUE if the Shift key is being + pressed.
ctrl	-	TRUE if the Control key is being + pressed.
alt	-	TRUE if the Alt key is being + pressed.
x	-	The X co-ordinate of the mouse, + relative to the top left of the display.
y	-	The Y co-ordinate of the mouse, + relative to the top left of the display.
b	-	The currently pressed buttons. + This should be made up of a bit mask composed + from GFX_BUTLEFT, GFX_BUTMIDDLE and GFX_BUTRIGHT.

typedef union GFXEvent
+    {
+    int      type;
+    GFXKey   key;
+    GFXMouse mouse;
+    } GFXEvent;

This defines the type for reporting + events (a combination of both mouse movements or key + presses). The fields are: + + + + + + + + + + + + + + + +

type	-	The type of event. This field is + just used to decide which of the other two fields + should be accessed to get the event information. + This field must be GFX_MOUSE_EVENT or + GFX_KEY_EVENT.
key	-	The GFXKey structure defining + the event if this is a GFX_KEY_EVENT.
mouse	-	The GFXMouse structure defining + the event if this is a GFX_MOUSE_EVENT.

+ +

The following interfaces must be supplied by the GFX object:

+ +

void GFX_init(void)

+ +

+
Initialises the GFX object. No other GFX interfaces are + called prior to this, with the possible (though current not + used) exception of GFX_exit().
+

+ +

void GFX_close(void)

+ +

+
Called when viDOOM is terminating. Note that other (none + system dependent) processing may go on between calling this + and then invoking exit() or return().
+

+ +

GFX_IMAGE GFX_create_image(GFX_BITMAP *bm)

+ +

+
Should create a GFX_IMAGE from the passed bitmap bm.
+

+ +

void GFX_destroy_image(GFX_IMAGE img)

+ +

+
Release the bitmap object pointed to by img.
+

+ +

void GFX_draw_image(GFX_IMAGE img, int x, int y)

+ +

+
Draws img with it's top-left co-ordinate + represented by x,y. This function should implement + any necessary clipping when drawing the bitmap.
+

+ +

void GFX_fill_screen(GFX_IMAGE img)

+ +

+
Should fill the screen with the image, scaled if + necessary. Note that this call is just used for the menu + backdrop, so if it cannot be honoured no harm will be done.
+

+ +

void GFX_open(int width, +int height)

+ +

+
Opens the display (or window or whatever) with the + specified width and height. Note that + failures in here should terminate the program.
+

+ +

void GFX_clear(int col)

+ +

+
This clears the display to the passed colour col.
+

+ +

void GFX_redraw(void)

+ +

+
This redraws the contents of the screen. All drawing + operations should not update the actual screen till this is + called (i.e. the display should be buffered).
+

+ +

void GFX_line(int x1, int y1, int x2, int y2, int +col)

+ +

+
Draw a line from x1,y1 to x2,y2 in + colour col.
+

+ +

void GFX_plot(int x, int y, int col)

+ +

+
Plot the point x,y in colour col.
+

+ +

void GFX_circle(int x, int y, int r, int col) +void GFX_fcircle(int x, int y, int r, int col)

+ +

+
Draw a circle centred on x,y with a radius r + and in colour col. The fcircle + version should draw a filled circle.
+

+ +

void GFX_rect(int x, int y, int w, int h, int col) +void GFX_frect(int x, int y, int w, int h, int col)

+ +

+
Draw a rectangle with one corner at x,y and the + other corner at (x+w),(y+h) in colour col. + Note that zero length and negative width and heights must be + allowed. The frect version should draw a + filled rectangle.
+

+ +

void GFX_set_XOR_mode(void) +void GFX_clear_XOR_mode(void)

+ +

+
This should set and clear XOR mode. Normally all GFX + operations should set the pixels to the colour specified, but + when XOR mode is enabled the pixel values should be XORed + into place.
+

+ +

void GFX_print(int x, int y, int col, char *fmt, +...)

+ +

+
Print the printf style arguments (fmt and ...) + with their top left corner at x,y in colour col. + Note that text should rendered transparently.
+

+ +

int GFX_fh(void) +int GFX_fw(void)

+ +

+
Return the height (GFX_fh) and width (GFX_fw) of the fixed + width font used for display purposes.
+

+ +

int GFX_mouse_buttons(void)

+ +

+
Returns the number of mouse buttons. This is just used as + check on initialisation as viDOOM expects at least 2 mouse + buttons.
+

+ +

int GFX_mouse(int *x, int *y)

+ +

+
Return the current point position in x and y. + If any of the passed pointers are NULL that variable should + be ignored.
+

+ +

void GFX_waitkey(GFXKEy *key)

+ +

+
Waits for a key to be pressed and returns the key + press in key. If key is NULL simply wait + for a key press.
+

+ +

int GFX_key(GFXKey *key)

+ +

+
Returns TRUE if a key has been pressed and returns the + keypress in key. Returns FALSE if there is no + outstanding keypresses, in which case the contents of key + are undefined.
+

+ +

void GFX_bounce(void)

+ +

+
Waits for all keys and mouse buttons to be released. On a + real event-driven system could be ignored, or flush any + outstanding events.
+

+ +

void GFX_await_input(GFXEvent *ev)

+ +

+
Waits for either a keypress or a mouse button to be + pressed and fills in ev accordingly.
+

+ +

void GFX_await_input_full(GFXEvent *ev)

+ +

+
Waits for either a keypress, a mouse button to be pressed + or the mouse to be moved and fills in ev + accordingly.
+

+ +

void GFX_exit(int code, char *fmt, ...)

+ +

+
This call should do any necessary tidying of the display + (switching from graphics mode, closing windows, whatever) + then display the printf style arguments (fmt and ...) + and the exit with the passed return code.
+

+ +

void GFX_save_screen(char *path)

+ +

+
This call need not be supported. It just allows screen + grabs to be captured when viDOOM is compiled with debug + information. If supported it should just save a bitmap in the + file pointed to by path.
+

+ +

Platform GUI

+ +

platgui.c

+ +

This provides access to the platform's GUI routines.

+ +

The following types are defined and used by the PLATGUI object +:

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

typedef struct
+    {
+    char      *text;
+    GFX_IMAGE img;
+    int       client_index;
+    } PLAT_IMG_PICKLIST;

This structure is used to define a + picklist that has graphical images and client defined + values attached to them. This is used for selection of + textures, flats and sprites (things) in viDOOM.

The + fields in the structure are:

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

text	-	This defines the text for a + picklist entry. NULL marks the end of the list of + picklist entries.
img	-	The GFX_IMAGE to associate with + this entry. Can be NULL to indicate show no + image.
client_index	-	The value returned if this item + is selected.

typedef struct
+    {
+    char   *text;
+    int    client_index;
+    } PLAT_PICKLIST;

This structure is used to define a + picklist that has client defined values attached to the + entries.

The fields in the structure are:

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

text	-	This defines the text for a + picklist entry. NULL marks the end of the list of + picklist entries.
client_index	-	The value returned if this item + is selected.

typedef struct
+    {
+    char  *text;
+    int   client_index;
+    } PLAT_MENU;

This structure is used to define menu + entries that have client defined values attached to them.

The + fields in the structure are:

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

text	-	This defines the text for the + menu entry. NULL marks the end of the list of + menu entries.
client_index	-	The value returned if this item + is selected.

typedef struct
+    {
+    char   *text;
+    int    client_index;
+    } PLAT_RADIO;

This structure is used to define entries + for a radio style picklist (i.e. where only one option + can be chosen) that have client defined values attached + to them.

The fields in the structure are:

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

text	-	This defines the text for the + radio button. NULL marks the end of the list of + radio button entries.
client_index	-	The value returned if this item + is selected.

typedef struct
+    {
+    char   *text;
+    int    type;
+    union /* Data */
+        {
+        int	i;
+        char	s[PLAT_DIAL_MAXSTRLEN+1];
+        double	d;
+        } data;
+    } PLAT_DIALOG;

This structure is used to define entries + for a simple dialog.

The fields in the structure are:

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

text	-	This defines the text for this + field in the dialog. NULL marks the end of the + list of dialog entries.
type	-	The type of field this is. + Possible values are PLAT_DIAL_STRING, + PLAT_DIAL_INTEGER and PLAT_DIAL_DOUBLE.
data.i	-	This is the field that is + displayed and updated on exit if the type is + PLAT_DIAL_INTEGER.
data.s	-	This is the field that is + displayed and updated on exit if the type is + PLAT_DIAL_STRING.
data.d	-	This is the field that is + displayed and updated on exit if the type is + PLAT_DIAL_DOUBLE.

+ +

Note that along with the types, the following predefined +values are set (these are read from the INI file). Note that they +should be considered to be unset until immediately prior to +viDOOM's call to GUI_setscreen():

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

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.
GUI_BOLD	The colour of bold text (used for + titles).

+ +

Functions

+ +

The following interfaces are defined by the PLATGUI object. +Note that all these calls are assumed to not destroy screen +contents (ie. the screen should be restored after displaying the +GUI object):

+ +

void GUI_setscreen(int width, int height)

+ +

+
Once the display has been opened with GFX_open() + then this is called to inform the platform's GUI routines of + the display size.
+

+ +

int GUI_yesno(char *question)

+ +

+
Display an alert with question in it and Yes + and No buttons. Returns TRUE if Yes is + pressed and FALSE if No is pressed.
+

+ +

int GUI_menu(char *title, int x, int y, PLAT_MENU +menu[], int defval)

+ +

+
Displays a menu with title title at position x,y. + The displayed items are taken from menu. The return + is the client_index field from the selected menu item, or defval + if the menu is cancelled.
+

+ +

char *GUI_fsel(char *title, char *default_path, +char filter)

+ +

+
Allows a file to be selected. The file selector should + have title for it's title and start selecting from + the default_path. If filter is NULL then + all files should be displayed, otherwise only files ending in + filter.
+
The return is NULL if the selector is cancelled. Otherwise + a pointer is returned containing the fully qualified path of + the selected file. This pointer must be dynamically allocated + and will be freed using FRelease().
+

+ +

int GUI_picklist(char *title, char *opts[])

+ +

+
Displays a picklist with title title. The options + are taken from the array of character pointers opts. + The return value is the index of the selected item in opts + if selected, or -1 if the picklist is cancelled.
+

+ +

int GUI_client_picklist(char *title, PLAT_PICKLIST +opts[], int defval)

+ +

+
Displays a picklist with title title. The text + items to display are taken from opts. The return is + the client_index field from the selected picklist item, or defval + if the picklist is cancelled.
+

+ +

int GUI_image_picklist(char *title, +PLAT_IMG_PICKLIST opts[], int defval)

+ +

+
Displays a picklist with title title. The text + items and associated image to display are taken from opts. + The return is the client_index field from the selected + picklist item, or defval if the picklist is + cancelled.
+

+ +

int GUI_radio_box(char *title, PLAT_RADIO opts[], +int current, int defval)

+ +

+
Displays a dialog containing radio buttons with title title. + The text to display is taken from opts. The selected + object when the the radio box is first displayed is the + option who's client_index field matches current (or + the first item if there is no match). The return is the + client_index field from the selected radio button, or defval + if the radio box is cancelled.
+

+ +

int GUI_multi_box(char *title, char *opts[], int +*val)

+ +

+
Display a mutli-selection radio box. The items are + described opts, which terminates with a NULL + pointer. Val points to a value which is used to + enable/disable the options dependent on the integers bit + setting. The integer pointed to by val is updated on + exit of the multi-selection box if it is not cancelled.
+
Note that the bit patterns are matched bit number to opt + index. ie.
+
+
val & 0x0001 corresponds to opts[0]
+
val & 0x0002 corresponds to opts[1] ...
+
val & 0x0010 corresponds to opts[4] ...
+
val & 0x0100 corresponds to opts[8] ...
+
val & 0x8000 corresponds to opts[15]
+
+
A maximum of 16 bits should be all that needs supporting + currently. The return is TRUE if the dialog is accepted, + otherwise FALSE.
+

+ +

int GUI_dialog(char *title, int no, PLAT_DIALOG +dial[])

+ +

+
Displays a dialog with the title title. The + fields for the dialog are extracted from dial, for + which there is expected to be no elements. The + return is TRUE if the dialog is accepted, or FALSE if it is + cancelled. On being cancelled the contents of the data union + within the dial elements is undefined.
+

+ +

File interface

+ +

file.c

+ +

This provides access to various file system functions and also +provides some filename manipulation routines. The following +interfaces should be provided:

+ +

char *Pwd(void)

+ +

+
This call should return the current working directory. The + return should be static.
+

+ +

void Cd(char *path)

+ +

+
This call should change the current working directory to path.
+

+ +

char *Dirname(char *path)

+ +

+
This call should return the directory part of path + if any. The return should be static.
+

+ +

char *Basename(char *path)

+ +

+
This call should return the filename part of path. + The return should be static, or a pointer into the path + parameter.
+

+ +

int FileExists(char *path)

+ +

+
This call should return TRUE if the file pointed to by path + exists.
+

+ +

int FilenamesEqual(char *path1, char *path2)

+ +

+
This call should return TRUE if the file pointed to by path1 + and path2 are the same file. At it's most basic + (e.g. like in the DOS port) it can simply makes sure that + directory separators are in the same form and then does strcasecmp() + on the paths.
+

+ +

Memory allocation

+ +

mem.c

+ +

This provides memory allocation. While memory allocation can +generally be done portably using malloc() providing this +library just covers for any possible OS dependent twist. Also +these routines are expected to handle errors internally. In all +the interfaces file and line parameters are +included so that errors can be reported more accurately.

+ +

The following interfaces should be provided:

+ +

void *FGrab (char *file, int line, int len)

+ +

+
This call should allocate len bytes and return a + pointer to it. A len of zero is valid. Memory should + be initialised to zero. Failure to allocate the memory should + terminate the program.
+

+ +

void *FReGrab (char *file, int line, void *ptr, +int len)

+ +

+
This call should re-allocate the memory pointed to by ptr + and return a new memory area of len bytes. The + original data pointed to by ptr should be copied to + the new memory area. Failure to allocate the memory should + terminate the program.
+

+ +

char *FStrdup (char *file, int line, char *str)

+ +

+
This call should allocate enough bytes to copy the nul + terminated str to it. The returned pointer should + point to the new copy of str. Failure to + allocate the memory should terminate the program.
+

+ +

void *FCopy (char *file, int line, void *ptr, int +len)

+ +

+
This call should allocate len bytes and copy len + bytes from ptr into the new area. The newly + allocated memory should be returned. Failure to allocate the + memory should terminate the program.
+

+ +

void FRelease (char *file, +int line, void *ptr)

+ +

+
This call should release the memory pointed to by ptr, + which will have been allocated by FGrab, FReGrab, FStrdup or + FCopy.
+

+ +

External command execution

+ +

runcmd.c

+ +

Provides a mechanism to run an external command. The following +interfaces should be provided:

+ +

int RunCommand(char *argv[], char *path)

+ +

+
Run a command. The output from the command (if there is + any) should NOT disturb the screen contents. The call should + return TRUE if the call succeeds, FALSE otherwise.
+
The argv list is an array of pointers to various + sections of the command and it's arguments, terminated with a + NULL pointer. Note that arguments may contain more than one + argument in each line - the actual command is described + simply by concatenating all the pointers together, eg.
+
argv[0]="bsp" + argv[1]="file.wad" + argv[2]="-o file.wad" + argv[3]=NULL
+
The path argument is a place to copy the path to + a file where the output from the command has been stored. If + this is not supported then the empty string should be + assigned to it. viDOOM will remove() the file after + it has read it.
+

+ +

Portable String routines

+ +

vstring.c

+ +

Provides common string functions that are not actually part of +the ANSI standard:

+ +

int StrCaseCmp(char *a, char *b)

+ +

+
Performs in exactly the same way as the ANSI strcmp() + function, save for the fact that the case of the strings + being compared is ignored.
+

+ +

int StrNCaseCmp(char *a, char *b)

+ +

+
Performs in exactly the same way as the ANSI strncmp() + function, save for the fact that the case of the strings + being compared is ignored.
+

+ +

Installation script

+ +

Each platform should provide a makefile called install. +This is invoked from the top level makefile like this:

+ +

+
cd $(PLATFORM) ; $(MAKEINSTALL)
+

+ +

Note that the install makefile will be invoked with the PLATFORM directory as the current working +directory.

+ +

The following files must be copied (where $SRC represents +the source build directory and $INSTALLDIR the install +directory):

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

`$SRC/vidoom`	`$INSTALLDIR/vidoom` Note that + this file may have a system specific extension (e.g. .EXE + in DOS) +
`$SRC/LICENSE`	`$INSTALLDIR/LICENSE` The GNU + GPL should be copied into the installation directory so that + binary distributions can be easily generated with the license + included. +
`$SRC/base.ini`	`$INSTALLDIR/vidoom.ini`
`$SRC/*.cfg`	`$INSTALLDIR/*.cfg`
`$SRC/doc/*.htm`	`$INSTALLDIR/doc/*.htm`
`$SRC/doc/*.png`	`$INSTALLDIR/doc/*.png`

+ +

Note that, obviously, any OS specific files should also be copied.

+ +

Documentation

+ +

If you release a port of viDOOM to any platform please update doc/bugs.htm with a contact address +for problems on that platform.

+ +

Back to index

+ +

$Id: porting.htm,v 1.19 2000/08/13 00:46:22 dosuser Exp dosuser $

+ + diff --git a/doc/thanks.htm b/doc/thanks.htm new file mode 100644 index 0000000..aae404f --- /dev/null +++ b/doc/thanks.htm @@ -0,0 +1,70 @@ + + + + + +viDOOM - Free Software DOOM editor + + + + +

Acknowledgements and Thanks

+ +

viDOOM could not have been written without help from the +following sources. Please mail me if there are any errors or I +have been misinformed on who actually did something.

+ +

Doom - id +Software
+Creators of DOOM, who thankfully wrote a terribly nice game and +then made it even nicer by making the WAD format simple and open. +

+ +

Unofficial Doom Specs - Matthew S Fell
+Writer and maintainer of the Unofficial +DOOM Specs. viDOOM would have been impossible without this +marvellous tome.

+ +

BSP - Colin Reed/ Lee Killough
+Developers of the BSP node builder. Without this viDOOM is +completely useless.

+ +

Maths help - Mathew Wilson
+Someone who knows much more maths than I ever will and writer of +the LinesCross() algorithm - saviour of the LINEDEF selection +code.

+ +

More maths help - comp.graphics.algorithms +FAQ
+Provided a much better 'is a point in a polygon?' than my +original one ever was...

+ +

Music - C64 Audio
+Call me sad, call me mad, or call me a nutter who needs to get +out more and find a life, but some of the Commodore 64 CDs and +MP3's didn't half help the coding and vague stabs at +documentation along some evenings.

+ +

VIM - Various +authors
+VI iMproved. My favourite editor, and inspiration (well, the +original) for the name viDOOM. Now, if only all these flash IDEs +would realise that people may actually want to use something +other than their own bundled multi-coloured swap-shop editors...

+ +

Back to index

+ +

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

+ + -- cgit v1.2.3