README: Reflect name changes, use simpler language, talk about FreeDM

Freedoom has grown to no longer focus on any single IWAD anymore, in
addition to becoming more of its own entity than a simple Doom-clone.

Use somewhat simpler language in the README, rather than bombing with
a technical term like IWAD right from the start, in addition to
explaining a bit more about what being Doom-compatible means.

The FreeDM project has spent a bit too much time in the shadows, even
moreso than the more recent Ultimate Doom-compatible IWAD. Give it
some spot light in the README and officially document its special
adherance to vanilla-compatibility.

Finally, lowercase "free software", even the FSF doesn't capitalize it
and we aren't writing in German in this document.
This commit is contained in:
Mike Swanson 2014-01-11 21:00:15 -08:00
parent 89daa45840
commit 63567a234e

View file

@ -1,20 +1,60 @@
= Freedoom = Freedoom
Freedoom is a project to create a complete Doom II-compatible IWAD file Freedoom is a project to create a complete Doom engine-based game
which is Free Software. which is free software, in addition to maintaining compatibility with
Doom modifications (``mods'') that have been released by the
continually-active community since 1993.
The IWAD file is the file used by Doom which contains all the game data Freedoom aims to create three ``IWAD'' files for the engine, each of
(graphics, sound effects, music, etc.). While the Doom source code is these is an independent sub-project representing different aims towards
Free, you currently still need one of the proprietary IWAD files from id game design and compatibility with Doom mods:
in order to play Doom. Freedoom aims to create a Free alternative.
Combined with the GPL-licensed Doom source code this will result in a [horizontal]
complete Free Doom-based game. *Freedoom: Phase 1*:: A four-chapter game, nine levels each, totalling
36 levels. This project aims for compatibility with The Ultimate Doom
(also known as plain Doom or Doom 1).
*Freedoom: Phase 2*:: A 32-level chapter featuring extra monsters and
a double-barrelled shotgun. This project aims for compatibility with
Doom II.
*FreeDM*:: 32 levels designed for competitive deathmatch play.
An ``IWAD'' file is used by the Doom engine, which contains all the
game data such as graphics, sound effects, music, and so on. While the
Doom engine source code is free, you would normally still need one of
the proprietary IWAD files from id Software in order to play
Doom. Freedoom aims to create a free alternative; combined with the
GPL-licensed Doom source code, results in a completely free
Doom-based game.
For more information, see http://freedoom.github.io/. For more information, see http://freedoom.github.io/.
== What ``Free Software'' means == How to play
When we speak of Free Software, we refer to the software movement in Hopefully, your engine of choice should already be capable of running
Freedoom without extra configuration. This may not be the case,
however, if the engine does not recognize any of the filenames for
Freedoom, and might require manual intervention to make it so. One of
the following options should do the trick:
* Use the +-iwad+ command line parameter. For example, to play Phase
2, you can enter +-iwad freedoom2.wad+ either from a command
prompt/terminal, or adding it to an application shortcut.
* Use the +DOOMWADPATH+ environment variable. Many engines support
this variable to add directories and/or IWADs to their search
path. The exact syntax matches your operating system's normal
+PATH+ environment variable.
* Rename the game IWADs. This may be a bit crude, but you can rename
the files to match those of Doom's. This is often the easiest
quick-fix, although it is normally desirable to use one of the
above methods if possible.
** +freedoom1.wad+ can be renamed to +doom.wad+
** +freedoom2.wad+ can be renamed to +doom2.wad+
** +freedm.wad+ can be renamed to +doom2.wad+
== What ``free software'' means
When we speak of free software, we refer to the software movement in
which your freedoms to use, copy, modify, and study it are ensured. For which your freedoms to use, copy, modify, and study it are ensured. For
example, you may freely use Freedoom for any purpose you see fit, you example, you may freely use Freedoom for any purpose you see fit, you
may redistribute it to anyone without needing to ask for permission, you may redistribute it to anyone without needing to ask for permission, you
@ -23,7 +63,7 @@ you may study it -- for example, to see how a Doom IWAD is built. To
facilitate this, you can get the full source code (here, in the form of facilitate this, you can get the full source code (here, in the form of
a DeuTex tree) for Freedoom. a DeuTex tree) for Freedoom.
You may read more about Free Software at the http://www.gnu.org/[GNU] You may read more about free software at the http://www.gnu.org/[GNU]
and http://www.fsf.org/[Free Software Foundation] websites. and http://www.fsf.org/[Free Software Foundation] websites.
== Contributing to Freedoom == Contributing to Freedoom
@ -31,7 +71,7 @@ and http://www.fsf.org/[Free Software Foundation] websites.
Contributions to Freedoom are always welcome, however there are a few Contributions to Freedoom are always welcome, however there are a few
guidelines that should be followed: guidelines that should be followed:
=== Intellectual Property === Intellectual property
We know people hate legalese, but this is important. This applies to We know people hate legalese, but this is important. This applies to
*everything* which is submitted. *everything* which is submitted.
@ -63,10 +103,20 @@ The general rules go as follows:
=== Levels === Levels
Levels should be in Boom format; you may exceed the limits of Vanilla Levels for Phase 1 and Phase 2 should be compatible with Boom 2.02: a
Doom and use Boom features; however, do not use features that are not Doom-derived engine which is a common ancester for many engines
supported by Boom 2.02 and compatible ports. Levels should be in Doom's today. Its extensions are even commonly reimplemented by engines which
original format, not in ``Hexen'' format. are not decended from Boom. This means that you may exceed the limits
of vanilla Doom and use features introduced in Boom. However, do not
use features that are not supported by Boom 2.02 and compatible
engines. Levels should be in Doom's original format, not in
``Hexen''-format.
Levels for FreeDM must strictly be vanilla-compatible, that is, they
must run in the original +doom2.exe+ engine for DOS and not cause any
VPOs and other such problems in the vanilla engine. This ensures the
maximum compatibility with all Doom-derived engines, including those
that do not descend from nor support Boom features.
It is sensible to also heed the following guidelines: It is sensible to also heed the following guidelines:
@ -79,46 +129,46 @@ It is sensible to also heed the following guidelines:
ports, especially those that use hardware accelerated rendering, may ports, especially those that use hardware accelerated rendering, may
not render it properly. Examples of tricks to avoid include those used not render it properly. Examples of tricks to avoid include those used
to simulate 3D bridges and ``deep water'' effects. to simulate 3D bridges and ``deep water'' effects.
* Boom removes almost all of the limits on rendering; however, do not * Boom removes almost all of the limits on rendering; however, do
make excessively complicated scenes. It is desirable that Freedoom not make excessively complicated scenes. It is desirable that
levels should be playable on old or low-powered hardware. Freedoom levels should be playable on low-powered hardware, such
* Always test in http://www.teamtnt.com/boompubl/boom2.htm[Boom] as phones and old computers.
itself rather than a derivative such as PrBoom. This ensures that * For Phase 1 and Phase 2, try to test in
your levels really are Boom-compatible rather than using any extra http://www.teamtnt.com/boompubl/boom2.htm[Boom] towards the end of
features. As DOS is rather rare these days, you may not have a your level creation process, before submission. Incompatibilities
system which can run Boom natively, so you may use either will usually be discovered before a release, but it will help to
http://www.dosbox.com/[DOSBox] or http://www.freedos.org/[FreeDOS]. be sure yourself. Since using DOS-compatible operating systems is
uncommon these days, you may need to use
http://www.dosbox.com/[DOSBox] or similar virtual machine software
to run Boom.
* For FreeDM, while you can test in the original +doom2.exe+ engine
with DOS or an emulator, this original engine is not free software
and not legally obtainable without Doom itself, in addition to the
hassle of merely running it.
http://www.chocolate-doom.org/[Chocolate Doom] is a free software,
highly-portable, and strictly-vanilla-compatible engine without
any extra features for levels, suitable for testing FreeDM.
=== Graphics === Graphics
* Graphics should be the same color and size as the originals to Graphics should generally have the same color and size as the original
remain compatible with PWADs (otherwise, they may end up looking Doom graphics, as to remain compatible with PWADs. Otherwise, such
like a mess). They cannot use the Doom font. levels may end up looking like a nightmare in design. They may be
* Textures should be the same dimensions as the originals. They thematically different as long as it still fits.
should be similar but not identical (to avoid IP infringement) --
in fact, they should be as different as possible while keeping to Doom uses a fictional corporation abbreviated as ``UAC'': this is
the general theme of the texture. As mentioned above, try to make trademarked by id Software and cannot be used in Freedoom. Instead,
a conscious effort to make the textures visibly different from the use the initials ``AGM'' for Freedoom.
originals. Critically, the textures should tile in the same way as
the originals.
* Some textures contain the letters UAC or references to UAC; this is
an intellectual property of id Software (trademarked). Instead, use
the letters AGM in your textures.
* Sprites should be roughly the same size and shape, but different to
the originals. Doom monsters are id's intellectual property (which
means no imps, cyberdemons, etc). The new monsters will behave the
same way as the originals, but will be totally new.
=== Documentation === Documentation
Freedoom always needs help with the documentation, so please send your Freedoom always needs help with the documentation, so please send your
patches, but keep in mind: patches, but keep in mind:
* We use http://www.methods.co.nz/asciidoc/[AsciiDoc] for writing the * We use http://asciidoc.org/[AsciiDoc] for writing the
documentation. AsciiDoc is a simple plaintext-based format which is documentation. AsciiDoc is a simple plaintext-based format which
simple to read and write in its source form, and makes pretty HTML is simple to read and write in its source form, and can generate
documents out of them (it also supports other formats like nice HTML documents out of them.
DocBook/PDF/manual pages...).
* Headers are formated in a wiki-style format, this makes it easier * Headers are formated in a wiki-style format, this makes it easier
for Vim (perhaps other editors, too) to automatically re-format for Vim (perhaps other editors, too) to automatically re-format
text. text.
@ -138,8 +188,8 @@ changes. You should prefix this line with the component you are commit
(for example, ``map17: fixed unbeatable map''). This should be (for example, ``map17: fixed unbeatable map''). This should be
followed by a blank line and more explanation if it's needed (for followed by a blank line and more explanation if it's needed (for
example, explaining what part of the map was broken). The commit example, explaining what part of the map was broken). The commit
2013-12-20T16:06:55Z!rjy@users.sourceforge.net shows a good example of `2013-12-20T16:06:55Z!rjy@users.sourceforge.net` shows a good example
a well-structured commit message. of a well-structured commit message.
You should commit often; each important change should get its own You should commit often; each important change should get its own
commit, but minor changes need not. Take advantage of git's ability to commit, but minor changes need not. Take advantage of git's ability to