freedoom
/
freedoom
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

documentation: change ascii ' quotes to either ’ or _ 

Non-reference AsciiDoc implementations such as AsciiDoctor (used by
GitHub) or even the simplistic parser in loccount choke up on these
characters for different reasons.  AsciiDoctor doesn’t seem to even
parse them, displaying them as-is and not with emphasized text.
loccount would get hung up on possessives, expecting a terminating
character for emphasis that never comes.

Annoying, but easy to work around.  the curly ’ character can be used
for possessives and _underscores_ can be used for emphasis.
master
Mike Swanson 2019-08-25 21:17:41 -07:00
parent 4ccdc785d0
commit 3b0f55db25
5 changed files with 35 additions and 37 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
BUILD-SYSTEM.adoc
View File

@ -5,7 +5,7 @@ system.
== Overview
Freedoom is built using 'deutex', which is a command-line tool for
Freedoom is built using `deutex`, which is a command-line tool for
automated building of Doom WAD files. However, multiple different WAD
files are built from the Freedoom material. Therefore, the Freedoom
build system is more complicated than a “normal” deutex build would
@ -62,7 +62,7 @@ system:
deutex is configured using a configuration file typically named
+wadinfo.txt+. In the case of Freedoom, multiple different WADs are
built from the common material, with slightly different settings for
each. Therefore, a 'master configuration file' named +buildcfg.txt+
each. Therefore, a _master configuration file_ named +buildcfg.txt+
is used to generate configuration files for each individual WAD to
build.
@ -80,7 +80,7 @@ based on the type of output target desired:
The texture configuration file is used to generate the texture lumps.
These are +texture1.lmp+ (texture directory), +pnames.lmp+ (list of
patch names) and +texture2.lmp+ (Doom I only). They are generated
by the +build-textures+ script; deutex's internal texture builder
by the +build-textures+ script; deutex’s internal texture builder
is deliberately not used for compatibility reasons.
Similarly to the build configuration file, different textures are
@ -208,13 +208,13 @@ the authentic retro feel.
Found in +lumps/dmxgus+, this script builds the +DMXGUS+ lump used for
GUS MIDI playback. The GUS (Gravis UltraSound) card was a gaming sound
card popular in the '90s. As with the +GENMIDI+ lump, few people are
card popular in the ’90s. As with the +GENMIDI+ lump, few people are
still using a real GUS card nowadays, but several source ports emulate
them and require this file.
== deutex
'deutex' is the tool used to generate the WAD files. It processes a
`deutex` is the tool used to generate the WAD files. It processes a
file typically named +wadinfo.txt+, reading files from the following
directories to generate the WAD:
@ -238,7 +238,7 @@ around. Some of them are listed here.
* deutex does not allow the exact path to the +texture1.txt+ file to
be specified in the configuration file; this used to be a problem
but the Freedoom's texture lumps are now built using a custom
but the Freedoom’s texture lumps are now built using a custom
script.
* deutex requires an existing IWAD file in order to build WAD files,

26
COMPILING.adoc
View File

@ -1,9 +1,9 @@
Compiling Freedoom
==================
This document is a general overview of Freedoom's dependencies
This document is a general overview of Freedoom’s dependencies
required to build it. See `README` for a description of what Freedoom
'is', and `BUILD-SYSTEM` for the technical details on 'how' Freedoom
_is_, and `BUILD-SYSTEM` for the technical details on _how_ Freedoom
is built.
Required software
@ -11,26 +11,24 @@ Required software
Building the Freedoom IWADs pretty much simply requires the following:
* 'make': While there is some attempt to keep our Makefiles
* _make_: While there is some attempt to keep our Makefiles
portable, testing does not really happen on anything but
https://www.gnu.org/software/make/[GNU Make] (patches to fix
portability are most welcome!). On non-GNU systems, it might be
available in a package and binary named as 'gmake'.
* 'Python': Freedoom uses several Python programs in its tree to
available in a package and binary named as _gmake_.
* _Python_: Freedoom uses several Python programs in its tree to
assist with building the IWADs. Both Python 2.7 and 3.x are fully
supported.
* 'Pillow': A Python image manipulation module that provides the
* _Pillow_: A Python image manipulation module that provides the
features we need for scaling and composing various graphics of the
game.
* 'DeuTex' 5.0: Freedoom depends on features developed in this
* _DeuTex_ 5.0: Freedoom depends on features developed in this
version of DeuTex and will not build on earlier versions. It is
available at https://github.com/Doom-Utils/deutex in source and
Windows binary formats. As of July 2017, this version is very
recent and may not be widely available in Unix distribution
repositories yet.
Windows binary formats.
All or most of this software should already be available in your
operating system's software repository, with the likely exception of
operating system’s software repository, with the likely exception of
DeuTex, which is easy to build.
Building Freedoom
@ -69,14 +67,14 @@ this document.
Optional software
-----------------
* 'Git': Freedoom is developed using the Git version control system,
* _Git_: Freedoom is developed using the Git version control system,
the latest developments can be tracked with it.
* 'AsciiDoc': The `*.adoc` files are all written in AsciiDoc markup,
* _AsciiDoc_: The `*.adoc` files are all written in AsciiDoc markup,
and it can be used to generate HTML versions of all these
documents. This is used as part of the `make dist` target, to
generate the `README.html` file for inclusion with official Zip
files.
* 'Zip': The `make dist` target uses Zip to create release archives
* _Zip_: The `make dist` target uses Zip to create release archives
for FreeDM, Phase 1, and Phase 2. This can also provide an easy
way to automate generating in-development versions for other
people.

16
README.adoc
View File

@ -48,7 +48,7 @@ https://zdoom.org/[GZDoom]. This engine offers good support for
single-player, multi-player, and the majority of mods created for both
_Doom_ and _Freedoom_.
On Windows, you should place _Freedoom_'s data files (those ending
On Windows, you should place _Freedoom_’s data files (those ending
with +.wad+) alongside the engine (eg, +odamex.exe+). On Unix-like
systems, these data files should go in either +/usr/share/games/doom+
or your home directory. If _Freedoom_ comes packaged as part of your
@ -72,10 +72,10 @@ of the following options should solve it:
line, or adding it to an application shortcut.
* Use the +DOOMWADPATH+ environment variable. Many engines support
this variable to add directories and/or files to their search
path. The exact syntax matches your operating system's normal
path. The exact syntax matches your operating system’s normal
+PATH+ environment variable.
* Rename the game files. This may be a bit crude, but you can
rename the files to match those of _Doom_'s. This is often the
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.
@ -147,7 +147,7 @@ The general rules go as follows:
Levels for _Phase 1_ and _Phase 2_ must be compatible with any limit
removing engine. This means that you may exceed the limits of the
original _Doom_, but do not depend on any additional mapping features.
Levels should be in _Doom_'s original format, not in “Hexen”-format.
Levels should be in _Doom_’s original format, not in “Hexen”-format.
It is a goal that future versions of _Freedoom_ will be entirely
vanilla-compatible, not even allowing expanded limits. Keeping this
@ -169,7 +169,7 @@ It is sensible to also heed the following guidelines:
* Try to make levels appropriately difficult for their position
within the progression of the game. Also bear in mind that not
all players may be as skilled a player as you.
* Do not use tricks that exploit _Doom_'s software renderer; some
* Do not use tricks that exploit _Doom_’s software renderer; some
engines, especially those that use hardware accelerated rendering,
may not render it properly. Examples of tricks to avoid include
those used to simulate 3D bridges and “deep water” effects.
@ -193,7 +193,7 @@ It is sensible to also heed the following guidelines:
Graphics should generally have the same color and size as the original
_Doom_ graphics, as to remain compatible with mods. Otherwise, levels
may end up looking like a nightmare in design. They may be
thematically different as long as it doesn't clash.
thematically different as long as it doesn’t clash.
_Doom_ uses a fictional corporation abbreviated as “UAC:” this is
trademarked by id Software and cannot be used in _Freedoom_. Instead,
@ -212,7 +212,7 @@ patches, but keep in mind:
for Vim (perhaps other editors, too) to automatically re-format
text.
* Text is kept at 72 characters wide. In Vim, you can set the
editor to automatically insert line breaks as you're typing by
editor to automatically insert line breaks as you’re typing by
performing `set textwidth=72`. Special exceptions to the width
rule might be allowed when necessary (for example, inserting long
URLs).
@ -252,7 +252,7 @@ You can also commit on a clone of the _Freedoom_ repository, although
this is a technical task and it is okay to let other _Freedoom_
maintainers to do it instead: that is our normal mode of operation.
However, pull requests are much appreciated and you may submit them in
any manner you wish, with GitHub's direct pull requests being the
any manner you wish, with GitHub’s direct pull requests being the
simplest, but by far not the only means.
Freedoom uses the commit message style commonly seen in distributed

4
dist/freedoom vendored
View File

@ -8,7 +8,7 @@ PORTS="doom odamex crispy-doom prboom-plus eternity gzdoom chocolate-doom"
# Just a single argument starting the command is allowed, -p, in order
# to explicitly set a port on the command line. -- is also supported
# so that -p can be instead sent directly to the port's argument list.
# so that -p can be instead sent directly to the port’s argument list.
if [ $# -gt 0 ]; then
if [ "$1" = "-p" ]; then
@ -54,7 +54,7 @@ for port in $PORTS; do
done
done
# If we've reached this far, no engine was successfully executed.
# If we’ve reached this far, no engine was successfully executed.
# print message to stderr and exit with a status of 1.
cat <<EOF >&2

14
dist/freedoom.adoc vendored
View File

@ -8,30 +8,30 @@ freedoom - Automatically launch Freedoom with an engine
SYNOPSIS
--------
*freedoom* ['-p' 'PORT'|'--'] ['ARGS']
*freedoom* [_-p_ _PORT_|_--_] [_ARGS_]
DESCRIPTION
-----------
Freedoom is a project to create a complete free-content game based on
the 'Doom' engine (often called “source ports” or simply “ports”),
the _Doom_ engine (often called “source ports” or simply “ports”),
which itself is free software. In addition, it maintains
compatibility with 'Doom' itself and is capable of playing the wide
compatibility with _Doom_ itself and is capable of playing the wide
variety of modifications (“mods”) that have been released by an
active community since 1993.
This command is a simple shell script to assist in running Freedoom,
which is not a game engine itself nor part of any engine project, but
playing Freedoom should remain simple. Only accepted as the first
argument, you may pass '-p PORT', which will run Freedoom using the
'PORT' specified. As an alternative, you may make a symbolic link
argument, you may pass _-p PORT_, which will run Freedoom using the
_PORT_ specified. As an alternative, you may make a symbolic link
named +$HOME/.doomport+ to your preferred port. A port specified on
the command line explicitly overrides +$HOME/.doomport+, whereas the
existence of the symbolic link will override the detection of port
based on a hard-coded list.
Additional arguments passed to the program, or after specifying '--'
Additional arguments passed to the program, or after specifying _--_
as the first option, will be passed to the engine being called. This
can allow you to use options such as '-file' to load mods or anything
can allow you to use options such as _-file_ to load mods or anything
else available with the engine of choice.
COPYRIGHT