Convert the rest of the doc files to Markdown.

HACKING.md

@@ -1,6 +1,4 @@
-
+# Coding style guidelines
-Coding style guidelines
-=======================
 
 The coding style guidelines for Chocolate Doom are designed to keep the
 style of the original source code.  This maintains consistency throughout
@@ -9,52 +7,57 @@ of these guidelines are stricter than what was done in the original
 source; follow these when writing new code only: there is no need to
 change existing code to fit them.
 
-You should set tabs to _display_ as eight spaces, not four.  However,
+You should set tabs to *display* as eight spaces, not four.  However,
-_indentation_ should be four spaces.  If possible, do not use tab
+*indentation* should be four spaces.  If possible, do not use tab
-characters at all.  There is a utility called "expand" which will remove
+characters at all.  There is a utility called “expand” which will remove
 tab characters.  For the reasoning behind this, see:
 http://www.jwz.org/doc/tabs-vs-spaces.html
 
 Please write code to an 80 column limit so that it fits within a standard
 80 column terminal. Do not leave trailing whitespace at the end of lines.
 
-Functions should be named like this: 'AB_FunctionName'.  The 'AB' prefix
+Functions should be named like this: `AB_FunctionName`.  The `AB` prefix
-denotes the subsystem (AM_ for automap, G_ for game, etc).  If a
+denotes the subsystem (`AM_` for automap, `G_` for game, etc).  If a
 function is static, you can omit the prefix and just name it like
-'FunctionName'.  Functions and global variables should always be made
+`FunctionName`.  Functions and global variables should always be made
 static if possible.
 
-Put '_t' on the end of types created with typedef.  Type names like this
+Put `_t` on the end of types created with typedef.  Type names like this
 should be all lowercase and have the subsystem name at the start. An
-example of this is 'txt_window_t'.  When creating structures, always
+example of this is `txt_window_t`.  When creating structures, always
 typedef them.
 
 Do not use Hungarian notation.
 
 Do not use the goto statement.
 
-Use C++-style comments, ie. '//' comments, not '/* ... */' comments.
+Use C++-style comments, ie. `//` comments, not `/* ... */` comments.
-I don't care that this isn't standard ANSI C.
+I don’t care that this isn’t standard ANSI C.
 
-Variables should be named like this: 'my_variable_name', not like this:
+Variables should be named like this: `my_variable_name`, not like this:
-'MyVariableName'.  In pointer variable declarations, place the '*' next
+`MyVariableName`.  In pointer variable declarations, place the `*` next
 to the variable name, not the type.
 
 When using an if, do, while, or for statement, always use the { } braces
 even when they are not necessary.  For example, do this:
 
-    if (condition)
+```c
-    {
+if (condition)
-        body;
+{
-    }
+    body;
+}
+```
 
 Not this:
 
-    if (condition)   // NO
+```c
-        body;
+if (condition)   // NO
+    body;
+```
 
 Write code like this:
 
+```c
 typedef struct
 {
     int member1;
@@ -117,81 +120,82 @@ void FunctionName(int argument, int arg2, int arg3, int arg4, int arg5,
 
     } while (condition);
 }
+```
 
-Security
+## Security
-========
 
 The C standard library has a number of unsafe functions that should be
 avoided when writing code for Chocolate Doom. These are:
 
-    Unsafe function       Safer alternative
+Unsafe function   |   Safer alternative
-    ---------------------------------------------
+------------------|------------------------
-    gets()                fgets(.., stdin)
+`gets()`          |  `fgets(.., stdin)`
-    sprintf               M_snprintf()
+`sprintf`         |  `M_snprintf()`
-    snprintf              M_snprintf()
+`snprintf`        |  `M_snprintf()`
-    vsprintf              M_vsnprintf()
+`vsprintf`        |  `M_vsnprintf()`
-    vsnprintf             M_vsnprintf()
+`vsnprintf`       |  `M_vsnprintf()`
-    strcpy()              M_StringCopy()
+`strcpy()`        |  `M_StringCopy()`
-    strncpy()             M_StringCopy()
+`strncpy()`       |  `M_StringCopy()`
-    strcat()              M_StringConcat()
+`strcat()`        |  `M_StringConcat()`
-    strncat()             M_StringConcat()
+`strncat()`       |  `M_StringConcat()`
-    strdup()              M_StringDuplicate()
+`strdup()`        |  `M_StringDuplicate()`
 
 Lots of the code includes calls to DEH_String() to simulate string
 replacement by the Dehacked tool. Be careful when using Dehacked
 replacements of printf format strings. For example, do not do this:
 
-    printf(DEH_String("foo %s"), s);
+```c
-    sprintf(mybuf, DEH_String("bar %s"), t);
+printf(DEH_String("foo %s"), s);
+sprintf(mybuf, DEH_String("bar %s"), t);
+```
 
 Instead do this:
 
-    DEH_printf("foo %s", s);
+```c
-    DEH_snprintf(mybuf, sizeof(mybuf), "bar %s", t);
+DEH_printf("foo %s", s);
+DEH_snprintf(mybuf, sizeof(mybuf), "bar %s", t);
+```
 
 This does the format string replacement safely in a way that checks
 the arguments securely.
 
-
+## Portability
-Portability
-===========
 
 Chocolate Doom is designed to be cross-platform and work on different
 Operating Systems and processors.  Bear this in mind when writing code.
 
-Do not use the long type (its size differs across platforms; use
+Do not use the `long` type (its size differs across platforms; use
-int or int64_t depending on which you want).
+`int` or `int64_t` depending on which you want).
 
-Use Doom's byte data type for byte data. 'int' is assumed to be a
+Use Doom’s byte data type for byte data. `int` is assumed to be a
-32-bit integer, and 'short' is a 16-bit integer. You can also use the
+32-bit integer, and `short` is a 16-bit integer. You can also use the
-ISO C99 data types: intN_t and uintN_t where N is 8,16,32,64.
+ISO C99 data types: `intN_t` and `uintN_t` where N is 8, 16, 32, 64.
 
 Be careful with platform dependencies: do not use Windows API
 functions, for example.  Use SDL where possible.
 
-Preprocessor #defines are set that can be used to identify the OS
+Preprocessor `#defines` are set that can be used to identify the OS
-if necessary: _WIN32 for Windows and __MACOSX__ for MacOS X. Others
+if necessary: `_WIN32` for Windows and `__MACOSX__` for Mac OS X. Others
 are set through SDL.  Try to avoid this if possible.
 
-Be careful of endianness!  Doom has SHORT() and LONG() macros that
+Be careful of endianness!  Doom has `SHORT()` and `LONG()` macros that
 do endianness conversion.  Never assume that integer types have a
 particular byte ordering.  Similarly, never assume that fields
 inside a structure are aligned in a particular way.  This is most
 relevant when reading or writing data to a file or a network pipe.
 
-For signed integers, you shouldn't assume that (i >> n) is the same as
+For signed integers, you shouldn’t assume that `(i >> n)` is the same as
-(i / (1 << n)).  However, most processors handle bitshifts of signed
+`(i / (1 << n))`.  However, most processors handle bitshifts of signed
-integers properly, so it's not a huge problem.
+integers properly, so it’s not a huge problem.
 
+## GNU GPL and licensing
 
-GNU GPL and licensing
+All code submitted to the project must be licensed under the GNU GPLv2 or a
-=====================
+compatible license.  If you use code that you haven’t 100% written
-
-All code submitted to the project must be licensed under the GNU GPL or a
-compatible license.  If you use code that you haven't 100% written
 yourself, say so. Add a copyright header to the start of every file.  Use
 this template:
 
+```
 //
 // Copyright(C) YEAR Author's name
 //
@@ -208,6 +212,4 @@ this template:
 //
 // *File description goes here*
 //
-
+```
-# vim: tw=70
-

Makefile.am

@@ -39,9 +39,9 @@ CODEBLOCKS_FILES=                              \
 
 DOC_FILES=                              \
         README.md                       \
-        README.Music                    \
+        README.Music.md                 \
-        NEWS                            \
+        NEWS.md                         \
-        PHILOSOPHY                      \
+        PHILOSOPHY.md                   \
         ChangeLog
 
 EXTRA_DIST=                             \
@@ -49,15 +49,15 @@ EXTRA_DIST=                             \
         $(MSVC_FILES)                   \
         $(CODEBLOCKS_FILES)             \
         $(DOC_FILES)                    \
-        NOT-BUGS                        \
+        NOT-BUGS.md                     \
-        README.Strife                   \
+        README.Strife.md                \
         .lvimrc                         \
-        HACKING                         \
+        HACKING.md                      \
-        TODO                            \
+        TODO.md                         \
         rpm.spec
 
 doomdocsdir = ${docdir}/../${PROGRAM_PREFIX}doom
-doomdocs_DATA = $(DOC_FILES) NOT-BUGS
+doomdocs_DATA = $(DOC_FILES) NOT-BUGS.md
 
 hereticdocsdir = ${docdir}/../${PROGRAM_PREFIX}heretic
 hereticdocs_DATA = $(DOC_FILES)
@@ -66,7 +66,7 @@ hexendocsdir = ${docdir}/../${PROGRAM_PREFIX}hexen
 hexendocs_DATA = $(DOC_FILES)
 
 strifedocsdir = ${docdir}/../${PROGRAM_PREFIX}strife
-strifedocs_DATA = $(DOC_FILES) README.Strife
+strifedocs_DATA = $(DOC_FILES) README.Strife.md
 
 MAINTAINERCLEANFILES =  $(AUX_DIST_GEN)
 

NOT-BUGS.md

@@ -1,37 +1,32 @@
-
 The aim of Chocolate Doom is to behave as closely to Vanilla Doom as
 possible.  As a result, you may experience problems that you would
-also experience when using Vanilla Doom.  These are not "bugs" as
+also experience when using Vanilla Doom.  These are not “bugs” as
 Chocolate Doom is behaving as intended.
 
 This is not intended to be a comprehensive list of Vanilla Doom bugs.
-For more information, consult the "engine bugs" page of the Doom Wiki.
+For more information, consult the “engine bugs” page of the Doom Wiki.
 
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+## Game exits after title screen with message about game version
-
-== Game exits after title screen with message about game version ==
 
 The game may exit after the title screen is shown, with a message like
 the following:
 
     Demo is from a different game version!
-    (read 106, should be 109)
+    (read 2, should be 109)
 
     *** You may need to upgrade your version of Doom to v1.9. ***
         See: https://www.doomworld.com/classicdoom/info/patches.php
-        This appears to be v1.6/v1.666.
+        This appears to be v1.0/v1.1/v1.2.
 
 This usually indicates that your IWAD file that you are using to play
 the game (usually named doom.wad or doom2.wad) is out of date.
-Chocolate Doom only supports the v1.9 IWAD file.
+Chocolate Doom only supports versions 1.666 through 1.9.
 
-To fix the problem, you must upgrade to the v1.9 IWAD file.  The URL
+To fix the problem, you must upgrade your IWAD file, preferably
-in the message has downloadable upgrade patches that you can use to
+to 1.9.  The URL in the message has downloadable upgrade patches that
-upgrade.
+you can use to upgrade.
 
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+## Game exits in demo loop when playing Final Doom
-
-== Game exits in demo loop when playing Final Doom ==
 
 When playing with the Final Doom IWAD files (tnt.wad, plutonia.wad),
 if you leave the game at the title screen to play through the demo
@@ -53,11 +48,9 @@ the alternate version, run with:
 
     chocolate-doom -gameversion final2
 
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+## Game exits when accessing the options menu
 
-== Game exits when accessing the options menu ==
+The game may exit with the message “Bad V_DrawPatch” when accessing
-
-The game may exit with the message "Bad V_DrawPatch" when accessing
 the options menu, if you have your mouse sensitivity set high.
 
 The Doom options menu has a slider that allows the mouse sensitivity
@@ -73,37 +66,35 @@ same thing.
 
 One solution to the problem is to set a lower mouse sensitivity.
 Alternatively, all of the settings in the options menu can be
-controlled through Doom's key bindings anyway:
+controlled through Doom’s key bindings anyway:
 
-    End game: F7
+Option                     | Key
-    Messages on/off: F8
+---------------------------|-----
-    Graphic detail high/low: F5
+End game                   | F7
-    Screen size smaller/larger: -/+
+Messages on/off            | F8
-    Sound volume menu: F4
+Graphic detail high/low    | F5
+Screen size smaller/larger | -/+
+Sound volume menu          | F4
 
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+## Game exits with “Savegame buffer overrun” when saving the game
-
-== Game exits with "Savegame buffer overrun" when saving the game ==
 
 If you are playing on a particularly large level, it is possible that
-when you save the game, the game will quit with the message "Savegame
+when you save the game, the game will quit with the message “Savegame
-buffer overrun".
+buffer overrun”.
 
 Vanilla Doom has a limited size memory buffer that it uses for saving
 games.  If you are playing on a large level, the buffer may be too
 small for the entire savegame to fit.  Chocolate Doom allows the limit
-to be disabled: in the setup tool, go to the "compatibility" menu and
+to be disabled: in the setup tool, go to the “compatibility” menu and
-disable the "Vanilla savegame limit" option.
+disable the “Vanilla savegame limit” option.
 
 If this error happens to you, your game has not been lost!  A file
 named temp.dsg is saved; rename this to doomsav0.dsg to make it appear
-in the first slot in the "load game" menu.  (On Unix systems, you will
+in the first slot in the “load game” menu.  (On Unix systems, you will
 need to look in the .chocolate-doom/savegames directory in your home
 directory)
 
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+## Game ends suddenly when recording a demo
-
-== Game ends suddenly when recording a demo ==
 
 If you are recording a very long demo, the game may exit suddenly.
 Vanilla Doom has a limited size memory buffer that it uses to save the
@@ -113,33 +104,27 @@ this happens, as the demo file will be around 131,072 bytes in size.
 You can work around this by using the -maxdemo command line parameter
 to specify a larger buffer size.  Alternatively, the limit can be
 disabled: in the setup tool, go to the compatibility menu and disable
-the "Vanilla demo limit" option.
+the “Vanilla demo limit” option.
 
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+## Game exits with a message about “visplanes”
-
-== Game exits with a message about "visplanes" ==
 
 The game may exit with one of these messages:
 
     R_FindPlane: no more visplanes
     R_DrawPlanes: visplane overflow (129)
 
-This is known as the "visplane overflow" limit and is one of the most
+This is known as the “visplane overflow” limit and is one of the most
 well-known Vanilla Doom engine limits.  You should only ever experience
 this when trying to play an add-on level.  The level you are trying to
 play is too complex; it was most likely designed to work with a limit
 removing source port.
 
-More information can be found here (archived link):
+More information can be found here (archived link): https://archive.is/s6h7V
 
-    https://archive.is/s6h7V
+## IDMUS## cheat doesn’t work with shareware/registered Doom IWADs
-
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-== IDMUS## cheat doesn't work with shareware/registered Doom IWADs ==
 
 The IDMUS cheat allows the in-game music to be changed.  However, in
-the original v1.9 this cheat didn't work properly when playing with
+the original v1.9 this cheat didn’t work properly when playing with
 the Doom 1 (shareware and registered) IWADs.  This bug was fixed in
 the Ultimate Doom and Final Doom executables.
 
@@ -149,9 +134,7 @@ properly.  If you are playing with the Ultimate Doom IWAD, the
 Ultimate Doom executable is emulated by default, so the cheat works
 properly.
 
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+## Some graphics are wrong when playing with BFG Edition IWADs
-
-== Some graphics are wrong when playing with BFG Edition IWADs ==
 
 If you are playing using the IWAD files from Doom 3: BFG Edition, you
 may notice that certain graphics appear strange or wrong. This
@@ -161,9 +144,6 @@ The IWAD files in the new BFG Edition have had some significant
 changes from the IWAD files in older releases. Some of the graphics
 lumps have been removed or changed, and the Doom 2 secret levels are
 also censored. Chocolate Doom includes some small workarounds that
-allow the game to run, but for the best experience, it's best to get a
+allow the game to run, but for the best experience, it’s best to get a
 copy of the classic versions of the IWADs. These are still available
-to buy from Steam or Id's online store.
+to buy from Steam or GOG.com.
-
-# vim: tw=70
-

PHILOSOPHY.md

@@ -1,39 +1,38 @@
-
 Chocolate Doom has been designed around a careful and deliberate
-philosophy that attempts to recreate the original ("Vanilla") DOS
+philosophy that attempts to recreate the original (“Vanilla”) DOS
 executables for Doom, Heretic, Hexen and Strife. This document
 describes some of that philosophy and the reasoning behind it.
 
 This document is descriptive, not proscriptive.
 
-== Vanilla behavior ==
+# Vanilla behavior
 
 Ideally Chocolate Doom aims to recreate the behavior of the Vanilla
 binaries, but different aspects of Vanilla behavior are held to
-varying degrees of importance. It can be imagined as different "tiers"
+varying degrees of importance. It can be imagined as different “tiers”
 of compatibility:
 
  * The game and gameplay itself is of central importance. Here, the
    Vanilla behavior ought to be maintained as accurately as possible.
    This includes the look, feel and sound, and things like demo
    compatibility.
- * The surrounding aspects of the game that aren't part of the central
+ * The surrounding aspects of the game that aren’t part of the central
-   gameplay experience can be extended as long as there's a good
+   gameplay experience can be extended as long as there’s a good
    reason and Vanilla behavior is respected.
  * The setup tool is not required to reproduce the behavior of the
    Vanilla setup tool, even though it reproduces its look and feel.
 
-"Vanilla" is defined as:
+“Vanilla” is defined as:
 
- * DOS Doom 1.9 (although there are actually multiple "1.9"s).
+ * DOS Doom 1.9 (although there are actually multiple “1.9”s).
  * DOS Heretic 1.3.
  * DOS Hexen 1.1.
  * DOS Strife 1.31.
 
-"Vanilla" does not include ports (either official or unofficial), such
+“Vanilla” does not include ports (either official or unofficial), such
 as console ports, Doom 95 or Doom 3: BFG Edition.
 
-== Compatibility ==
+# Compatibility
 
 Chocolate Doom aims to be compatible with Vanilla Doom in several
 different ways. Examples are:
@@ -41,12 +40,12 @@ different ways. Examples are:
  * Bug compatibility: the aim is to emulate compatibility of the
    original game down to bugs that were present in the DOS
    executables. This includes maintaining the limitations of the
-   original engine: for example, the infamous "visplane overflow" bug
+   original engine: for example, the infamous “visplane overflow” bug
    is intentionally still present, where other source ports have
    removed it; this allows mappers targeting Vanilla Doom to use
    Chocolate Doom as a faithful substitute.
  * Demo compatibility: Doom was one of the first games to develop a
-   'speedrunning' community, and thousands of recordings of Doom
+   ‘speedrunning’ community, and thousands of recordings of Doom
    gameplay (.lmp demo files) exist in the Compet-N archive. Chocolate
    Doom aims for the highest standard of demo compatibility with
    Vanilla Doom, a goal that is often complicated by obscure behavior
@@ -60,9 +59,9 @@ different ways. Examples are:
    file format as Vanilla, such that it should be possible to import
    and use existing savegame files.
 
-== DOS tools ==
+# DOS tools
 
-Chocolate Doom includes some features that aren't part of Vanilla Doom
+Chocolate Doom includes some features that aren’t part of Vanilla Doom
 but exist for compatibility with DOS tools that interact with it.
 These are considered part of the Vanilla experience and ought to be
 treated as such. Some examples are:
@@ -73,7 +72,7 @@ treated as such. Some examples are:
    does under DOS. Chocolate Doom imposes the same limitations that
    Vanilla Dehacked does.
 
-== Exceptions ==
+# Exceptions
 
 Chocolate Doom differs from Vanilla Doom in a number of ways. In most
 cases these are subtle, minor differences. Nonetheless they deserve
@@ -81,25 +80,25 @@ some explanation and justification. Here are some examples of
 situations where changes are considered acceptable:
 
  1. Vanilla behavior can be broken that is harmful, eg. can damage the
-    player's computer, or is just outright misleading. For example:
+    player’s computer, or is just outright misleading. For example:
 
     - Vanilla uses unbounded sprintf and strcpy (security issue).
     - Vanilla has crashes that force the user to reboot the machine.
     - Vanilla has an out of memory message that recommends tweaking
-      CONFIG.SYS. As Chocolate Doom doesn't run under DOS, reproducing
+      CONFIG.SYS. As Chocolate Doom doesn’t run under DOS, reproducing
       this message would not be helpful.
 
- 2. Subtly extending behavior is okay where it's not clear what the
+ 2. Subtly extending behavior is okay where it’s not clear what the
     Vanilla behavior is anyway. For example:
 
     - Opening the menu releases mouse grab in Chocolate Doom.
-    - Chocolate Hexen's graphical startup screen runs in a window.
+    - Chocolate Hexen’s graphical startup screen runs in a window.
 
- 3. Supporting obsolete technology is not a goal: it's considered
+ 3. Supporting obsolete technology is not a goal: it’s considered
     acceptable that Chocolate Doom does not support every type of
     hardware from 1993. However, Chocolate Doom should aim to recreate
     the functionality in a modern way. Examples of technology that
-    isn't supported are:
+    isn’t supported are:
 
     - No support for IPX networks, but TCP/IP is supported instead.
     - No support for dial-up/serial connections; modern operating
@@ -109,35 +108,39 @@ situations where changes are considered acceptable:
  4. Changes are acceptable that allow the player to be able play the
     game. For example:
 
-    - There are new key bindings for actions that can't be rebound with
+    - There are new key bindings for actions that can’t be rebound with
-      Vanilla Doom, because it's useful for portability to machines
+      Vanilla Doom, because it’s useful for portability to machines
-      that don't have a full keyboard.
+      that don’t have a full keyboard.
     - There are additional mouse and joystick key bindings that let you
       perform actions with them that can only be done with the keyboard
       in Vanilla Doom.
     - Chocolate Doom includes some hacks to support the Doom 3: BFG
       Edition IWAD files. The assumption is that being able to at least
-      play is better than nothing, even if it's not Vanilla behavior.
+      play is better than nothing, even if it’s not Vanilla behavior.
+    - Chocolate Strife does not emulate the save bug from
+      Vanilla 1.31, which could corrupt saves when overwriting a slot,
+      if the old slot was not part of the current game’s progression.
+      Vanilla behavior is unexpected and potentially devastating.
 
  5. Adding extra options to Vanilla functionality is acceptable as long
-    as the defaults match Vanilla, it doesn't change gameplay and
+    as the defaults match Vanilla, it doesn’t change gameplay and
-    there's a good reason for it. For example:
+    there’s a good reason for it. For example:
 
     - PNG screenshots are supported because PCX is an obsolete format.
     - Chocolate Doom has the vanilla_keyboard_mapping option that
       allows the user to use the native keyboard mapping for their
       computer, rather than always assuming a US layout.
 
- 6. Changing configuration file defaults is acceptable where there's a
+ 6. Changing configuration file defaults is acceptable where there’s a
     very good reason. For example:
 
     - Vanilla Doom defaults to no sound or music if a configuration
       file is not found. Chocolate Doom defaults to having sound
       effects and music turned on by default, because modern computers
-      support these; there's no need to configure hardware IRQ settings
+      support these; there’s no need to configure hardware IRQ settings
       to get sound working.
 
- 7. Things can be changed if they're really just inconsequential. For
+ 7. Things can be changed if they’re really just inconsequential. For
     example:
 
     - The startup messages in Chocolate Doom are not identical to
@@ -146,22 +149,22 @@ situations where changes are considered acceptable:
       -regdev used by id internally for development; these have been
       removed.
 
-A good litmus test of when it's acceptable to break from Vanilla
+A good litmus test of when it’s acceptable to break from Vanilla
-behavior is to ask the question: "Although this is Vanilla behavior,
+behavior is to ask the question: “Although this is Vanilla behavior,
-is there anyone who would want this?".
+is there anyone who would want this?”
 
 For example, emulating Vanilla bugs like the visplane overflow bug is
 something that is useful for people making Vanilla format maps. On the
 other hand, painstakingly emulating Vanilla Doom by starting with no
 sound or music by default is not helpful to anyone.
 
-== Minimalism ==
+# Minimalism
 
 Chocolate Doom aims to be minimalist and straightforward to configure;
 in particular, the setup tool should have a sane interface. Part of
-the inspiration for Chocolate Doom came from Boom's complicated maze
+the inspiration for Chocolate Doom came from Boom’s complicated maze
 of options menus (and a desire to avoid them). Too many preferences
-lead to a bad user interface; see Havoc Pennington's essay on Free
+lead to a bad user interface; see Havoc Pennington’s essay on Free
 Software UI:
 
   http://ometer.com/free-software-ui.html
@@ -173,21 +176,21 @@ the setup tool. The assumption is that if you care enough about those
 obscure features, editing a configuration file by hand should not be a
 huge problem for you.
 
-Also inspirational was the README file from Havoc's Metacity window
+Also inspirational was the README file from Havoc’s Metacity window
 manager, where the list of features begins:
 
-  Boring window manager for the adult in you. Many window managers
+  > Boring window manager for the adult in you. Many window managers
-  are like Marshmallow Froot Loops; Metacity is like Cheerios.
+  > are like Marshmallow Froot Loops; Metacity is like Cheerios.
 
-I'd like to think that Chocolate Doom's philosophy towards features is
+I’d like to think that Chocolate Doom’s philosophy towards features is
 similar. The idea is for a source port that is boring. I find the best
 software - both proprietary and open source - is software that is
-"egoless": it does a job well without pretentions about its importance
+“egoless”: it does a job well without pretentions about its importance
 or delusions of grandeur. A couple of other notable examples of
 software that I feel embody this spirit of design in a beautiful way
-are Marco Pesenti Gritti's Epiphany web browser and Evince PDF viewer.
+are Marco Pesenti Gritti’s Epiphany web browser and Evince PDF viewer.
 
-== Other philosophical aspects ==
+# Other philosophical aspects
 
 Chocolate Doom aims for maximal portability. That includes running on
 many different CPUs, different operating systems and different devices
@@ -195,6 +198,3 @@ many different CPUs, different operating systems and different devices
 
 Chocolate Doom is and will always remain Free Software. It will never
 include code that is not compatible with the GNU GPL.
-
-# vim: tw=70
-

README.Music.md

@@ -1,16 +1,15 @@
-
 Doom has a memorable and atmospheric soundtrack. Like many games of
 the era, it is MIDI-based. Chocolate Doom includes a number of
 different options for music playback, detailed below.
 
-== Native MIDI playback ==
+## Native MIDI playback
 
 Most modern operating systems have some kind of built-in support for
 MIDI playback; some have very good quality MIDI playback (Mac OS X for
-example). To use this, choose "Native MIDI" in the sound configuration
+example). To use this, choose “Native MIDI” in the sound configuration
 dialog in the setup tool.
 
-== Timidity ==
+## Timidity
 
 Timidity is a software-based MIDI synthesizer, and a version of it is
 included in the SDL_mixer library used by Chocolate Doom. To use
@@ -20,17 +19,17 @@ from the idgames archive as sounds/eawpats.zip:
 
   https://www.doomworld.com/idgames/sounds/eawpats
 
-Having installed a sound font, select "Native MIDI" in the sound
+Having installed a sound font, select “Native MIDI” in the sound
-configuration dialog in the setup tool, and use the "Timidity
+configuration dialog in the setup tool, and use the “Timidity
-configuration file" widget below to enter the path to the Timidity
+configuration file” widget below to enter the path to the Timidity
 configuration file (normally named timidity.cfg).
 
-== Gravis Ultrasound (GUS) ==
+## Gravis Ultrasound (GUS)
 
-The Gravis Ultrasound (GUS) was a PC sound card popular in the '90s,
+The Gravis Ultrasound (GUS) was a PC sound card popular in the ’90s,
 notable for having wavetable synthesis that provided MIDI playback
 that was superior to most other cards of the era. Chocolate Doom
-includes a "pseudo-GUS emulation" feature that simulates the GUS
+includes a “pseudo-GUS emulation” feature that simulates the GUS
 (using Timidity, under the hood).
 
 To use this feature you need a copy of the GUS patch files that were
@@ -41,37 +40,37 @@ from the idgames archive as music/dgguspat.zip:
 
   https://www.doomworld.com/idgames/music/dgguspat
 
-Having downloaded the patches, select "GUS (emulated)" in the sound
+Having downloaded the patches, select “GUS (emulated)” in the sound
-configuration dialog in the setup tool, and use the "GUS patch path"
+configuration dialog in the setup tool, and use the “GUS patch path”
 widget to enter the path to the directory containing the patch files.
 
 By default a GUS card with 1024KB is simulated; to simulate a 256KB,
 512KB or 768KB card instead, change the gus_ram_kb option in
 chocolate-doom.cfg.
 
-== OPL (Soundblaster / Adlib) ==
+## OPL (Soundblaster / Adlib)
 
-Most people playing Doom in the '90s had Soundblaster-compatible sound
+Most people playing Doom in the ’90s had Soundblaster-compatible sound
 cards, which used the Yamaha OPL series of chips for FM-based MIDI
 synthesis. Chocolate Doom includes the ability to emulate these chips
 for a retro experience. OPL emulation is the default MIDI playback,
-but can be selected in the setup tool as "OPL (Adlib/SB)".
+but can be selected in the setup tool as “OPL (Adlib/SB)”.
 
 Most modern computers do not include an OPL chip any more, as CPUs are
 fast enough to do decent software MIDI synthesis. However, no software
 emulator sounds exactly like a real (hardware) OPL chip, and a few
-cards do have real hardware OPL. If you have such a card, here's how
+cards do have real hardware OPL. If you have such a card, here’s how
 to configure Chocolate Doom to use it.
 
-=== Sound cards with OPL chips ===
+# Sound cards with OPL chips
 
 If you have an ISA sound card, it almost certainly includes an OPL
-chip. Modern computers don't have slots for ISA cards though, so you
+chip. Modern computers don’t have slots for ISA cards though, so you
 must be running a pretty old machine.
 
-If you have a PCI sound card, you probably don't have an OPL chip.
+If you have a PCI sound card, you probably don’t have an OPL chip.
 However, there are some exceptions to this. The following cards are
-known to include "legacy" OPL support:
+known to include “legacy” OPL support:
 
   * C-Media CMI8738 (*)
   * Forte Media FM801
@@ -93,31 +92,31 @@ one of these cards for sale cheap on eBay.
 For the cards listed above with (*) next to them, OPL support is
 disabled by default and must be explictly enabled in software.
 
-If your machine is not a PC, you don't have an OPL chip, and you will
+If your machine is not a PC, you don’t have an OPL chip, and you will
 have to use the software OPL.
 
-=== Operating System support ===
+# Operating System support
 
-If you're certain that you have a sound card with hardware OPL, you
+If you’re certain that you have a sound card with hardware OPL, you
 may need to take extra steps to configure your operating system to
 allow access to it. To do hardware OPL, Chocolate Doom must access
 the chip directly, which is usually not possible in modern operating
 systems unless you are running as the superuser (root/Administrator).
 
-=== Windows 9x ===
+## Windows 9x
 
-If you're running Windows 95, 98 or Me, there is no need to configure
+If you’re running Windows 95, 98 or Me, there is no need to configure
 anything. Windows allows direct access to the OPL chip. You can
 confirm that hardware OPL is working by checking for this message in
 stdout.txt:
 
-  OPL_Init: Using driver 'Win32'.
+    OPL_Init: Using driver 'Win32'.
 
-=== Windows NT (including 2000, XP and later) ===
+## Windows NT (including 2000, XP and later)
 
-If you're running an NT-based system, it is not possible to directly
+If you’re running an NT-based system, it is not possible to directly
 access the OPL chip, even when running as Administrator. Fortunately,
-it is possible to use the "ioperm.sys" driver developed for Cygwin:
+it is possible to use the “ioperm.sys” driver developed for Cygwin:
 
   http://openwince.sourceforge.net/ioperm/
 
@@ -128,44 +127,41 @@ executable and it should be automatically loaded.
 You can confirm that hardware OPL is working by checking for this
 message in stdout.txt:
 
-  OPL_Init: Using driver 'Win32'.
+    OPL_Init: Using driver 'Win32'.
 
-=== Linux ===
+## Linux
 
 If you are using a system based on the Linux kernel, you can access
 the OPL chip directly, but you must be running as root. You can
 confirm that hardware OPL is working, by checking for this message on
 startup:
 
-  OPL_Init: Using driver 'Linux'.
+    OPL_Init: Using driver 'Linux'.
 
 If you are using one of the PCI cards in the list above with a (*)
 next to it, you may need to manually enable FM legacy support. Add
 the following to your /etc/modprobe.conf file to do this:
 
-  options snd-ymfpci fm_port=0x388
+    options snd-ymfpci fm_port=0x388
-  options snd-cmipci fm_port=0x388
+    options snd-cmipci fm_port=0x388
 
-=== OpenBSD/NetBSD ===
+## OpenBSD/NetBSD
 
 You must be running as root to access the hardware OPL directly. You
 can confirm that hardware OPL is working by checking for this message
 on startup:
 
-  OPL_Init: Using driver 'OpenBSD'.
+    OPL_Init: Using driver 'OpenBSD'.
 
 There is no native OPL backend for FreeBSD yet. Sorry!
 
-== Other options ==
+# Other options
 
-If you have some other favorite MIDI playback option that isn't
+If you have some other favorite MIDI playback option that isn’t
 listed above, you can set a hook to invoke an external command for
-MIDI playback using the 'snd_musiccmd' configuration file option. For
+MIDI playback using the ‘snd_musiccmd’ configuration file option. For
 example, set:
 
-  snd_musiccmd    "aplaymidi -p 128:0"
+    snd_musiccmd    "aplaymidi -p 128:0"
 
 in your chocolate-doom.cfg file.
-
-# vim: set tw=70:
-

README.Strife.md

@@ -1,6 +1,6 @@
-===============================================================================
+````````````````````````````````````````````````````````````````````````
 
-          Samuel 'Kaiser' Villarreal and James 'Quasar' Haley Present
+          Samuel ‘Kaiser’ Villarreal and James ‘Quasar’ Haley Present
 
            C      H      O      C      O      L      A      T      E
             ______________________________._________________________
@@ -10,17 +10,17 @@
           /_______  /  |____|    |____|_  /___|\___  /   /_______  /
                   \/                    \/         \/            \/
 
-===============================================================================
+````````````````````````````````````````````````````````````````````````
 
-* What is it? *
+## What is it?
 
 Chocolate Strife is the most accurate and complete recreation of Rogue
-Entertainment's "Strife: Quest for the Sigil." It was created through more than
+Entertainment’s “Strife: Quest for the Sigil.”  It was created through more
-four years of reverse engineering effort with the blessings of the original
+than four years of reverse engineering effort with the blessings of the
-programmers of the game.
+original programmers of the game.
 
 
-* Why? *
+## Why?
 
 The source code for Strife was lost, which means, unlike the code for all the
 other commercial DOOM-engine games, it cannot be released. The only access we
@@ -32,7 +32,7 @@ resulting Chocolate Doom-based executable is as close as possible to the
 original.
 
 
-* Is it Legal? *
+## Is it Legal?
 
 Chocolate Strife was originally reverse-engineered from the DOS Strife
 binaries. Although reverse engineering is legally a protected activity, this
@@ -45,9 +45,9 @@ Edition, along with its GPL-licensed source code, constitutes tacit approval
 for the legal status of Chocolate Strife by its current copyright holder.
 
 
-* Is it Perfect? *
+## Is it Perfect?
 
-Almost, but not entirely! That's where you come in. Help us by reporting any
+Almost, but not entirely! That’s where you come in. Help us by reporting any
 discrepancies you may notice between this executable and the vanilla DOS
 program!
 
@@ -60,16 +60,20 @@ for example by initializing pointers to NULL rather than using them without
 setting a value first.
 
 
-* What are some known problems? *
+## What are some known problems?
 
-- The demo version is *not* supported, and there are not any current plans
+The demo version is *not* supported, and there are not any current plans to
-  to support it in the future, due to the vast number of differences (the
+support it in the future, due to the vast number of differences (the demo
-  demo version of Strife is based on a much earlier beta version of Rogue's
+version of Strife is based on an earlier version of Rogue’s
-  codebase). You should use a commercial Strife IWAD file, preferably of
+codebase).
-  version 1.2 or later.
+
+The commercial Strife IWAD version 1.1 may run, but also exhibit issues.  Like
+the demo version, there are no current plans to fully support it.  Make sure
+your copy is updated to at least 1.2.  Strife: Veteran Edition already
+includes the required version.
 
 
-* How do I use it? *
+## How do I use it?
 
 From the Run box or a command line, issue a command to Chocolate Strife just
 like you would run Chocolate Doom. Most of the same command line parameters
@@ -82,27 +86,27 @@ redundant and unnecessary.
 
 Some new command-line parameters in Chocolate Strife include the following:
 
--nograph
+  - -nograph
-  Disables the graphical introduction sequence. -devparm implies this.
+    - Disables the graphical introduction sequence. -devparm implies this.
 
--novoice
+  - -novoice
-  Disables voices even if voices.wad can be found.
+    - Disables voices even if voices.wad can be found.
 
--work
+  - -work
-  Enables Rogue's playtesting mode. Automatic godmode, and pressing the
+    - Enables Rogue’s playtesting mode. Automatic godmode, and pressing the
-  inventory drop key will toggle noclipping.
+      inventory drop key will toggle noclipping.
 
--flip
+  - -flip
-  Flips player gun graphics. This is buggy, however, because it does not
+    - Flips player gun graphics. This is buggy, however, because it does not
-  reverse the graphics' x offsets (this is an accurate emulation of the
+      reverse the graphics’ x offsets (this is an accurate emulation of the
-  vanilla engine's behavior).
+      vanilla engine’s behavior).
 
--random
+  - -random
-  Randomizes the timing and location of item respawns in deathmatch, when
+    - Randomizes the timing and location of item respawns in deathmatch, when
-  item respawning is enabled.
+      item respawning is enabled.
 
 
-* Copyright *
+## Copyright
 
 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
@@ -113,9 +117,8 @@ 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.
 
-See the "COPYING" file for the full license text. The source code for this
+See the “COPYING” file for the full license text. The source code for this
 program is available from the same location where you downloaded this package.
 
 Aside from Chocolate Doom, portions of the code are derived from the Eternity
 Engine, Copyright 2011 Team Eternity, as published under the GNU GPL.
-

TODO.md

@@ -1,20 +1,20 @@
-This is Chocolate Doom's "to do" list. Note that this is kind of an arbitrary
+This is Chocolate Doom’s “to do” list. Note that this is kind of an arbitrary
 and unstructured wish list of features and improvements. The bug tracker
 (http://chocolate-doom.org/bugs) has more feature requests.
 
 * Multiplayer:
-  - Use UPnP to automatically configure port forwarding for NATted
+  - Use UPnP to automatically configure port forwarding for NATed
     networks.
   - Multiplayer options and configuration file (server name, etc)
 * Improve multiplayer startup:
-  - Select an IWAD automatically from the server's game type rather than
+  - Select an IWAD automatically from the server’s game type rather than
     all players having to specify -iwad.
   - Send list of WADs to load instead of all clients having to specify -file.
   - Same applies to dehacked patches and wad merging parameters.
 * Portability improvements:
-  - Test on and fix for architectures where ((-2) >> 1) != -1
+  - Test on and fix for architectures where `((-2) >> 1) != -1`
-  - Use size-specific types (eg. int32_t instead of int)
+  - Use size-specific types (eg. `int32_t` instead of int)
-  - Don't make structure packing assumptions when loading levels.
+  - Don’t make structure packing assumptions when loading levels.
   - Port to every OS and architecture under the sun
   - Port to Emscripten and release a web-based version.
 * Video capture mode
@@ -24,16 +24,13 @@ and unstructured wish list of features and improvements. The bug tracker
   - Merge r_draw.c to common version and delete duplicates
   - Heretic v1.2 emulation (if possible)
   - Hexen v1.0 emulation (if possible/necessary)
-  - Strife v1.2 emulation (for demo IWAD support)
+  - Strife v1.1 emulation (for demo IWAD support)
   - Screensaver mode
 
 Crazy pie in the sky ideas:
 
 * Automatic WAD installer - download and run TCs from a list automatically
-  (automating the current "instructions on wiki" system).
+  (automating the current “instructions on wiki” system).
 * Textscreen interface to the Compet-N database: menu driven system to
   automatically download and play speedruns.
 * DWANGO-like interface for finding players and setting up games.
-
-# vim: tw=70
-

pkg/config.make.in

@@ -19,8 +19,8 @@ PACKAGE_VERSION = @PACKAGE_VERSION@
 
 # Documentation files to distribute with packages.
 
-DOC_FILES = README.md     \
+DOC_FILES = README.md        \
-            README.Music  \
+            README.Music.md  \
-            COPYING       \
+            COPYING          \
-            NEWS
+            NEWS.md
 

pkg/osx/GNUmakefile

@@ -6,7 +6,7 @@
 
 include ../config.make
 
-DOC_FILES += README.Strife NOT-BUGS
+DOC_FILES += README.Strife.md NOT-BUGS.md
 
 export MACOSX_DEPLOYMENT_TARGET=10.7
 
@@ -72,7 +72,7 @@ $(STAGING_DIR): launcher $(TOPLEVEL_DOCS)
 	cp $(TOPLEVEL_DOCS) "$(APP_DOC_DIR)"
 
 	ln -s "$(APP_DOC_RELDIR)/COPYING" "$(STAGING_DIR)/Software License"
-	ln -s "$(APP_DOC_RELDIR)/README" "$(STAGING_DIR)/README"
+	ln -s "$(APP_DOC_RELDIR)/README.md" "$(STAGING_DIR)/README.md"
 	ln -s /Applications "$(STAGING_DIR)"
 
 	cp launcher "$(APP_BIN_DIR)"

pkg/win32/GNUmakefile

@@ -27,12 +27,12 @@ $(STRIFE_ZIP): staging-strife hook-strife
 # Special hooks to custom modify files for particular games.
 
 hook-doom: staging-doom
-	cp $(TOPLEVEL)/NOT-BUGS $</NOT-BUGS.txt
+	cp $(TOPLEVEL)/NOT-BUGS.md $</NOT-BUGS.txt
 
 # Chocolate Strife has its own custom README file:
 
 hook-strife: staging-strife
-	cp $(TOPLEVEL)/README.Strife $</README.txt
+	cp $(TOPLEVEL)/README.Strife.md $</README.txt
 
 # Build up a staging dir for a particular game.
 
@@ -45,13 +45,10 @@ staging-%:
 	   $@/$(PROGRAM_PREFIX)$*-setup.exe
 	$(STRIP) $@/*.exe
 	
-	for f in $(DOC_FILES); do                    \
+	for f in $(DOC_FILES); do                                    \
-		cp $(TOPLEVEL)/$$f $@/$$f.txt;       \
+		cp $(TOPLEVEL)/$$f $@/$(shell basename $$f .md).txt; \
 	done
 	cp $(TOPLEVEL)/man/CMDLINE.$* $@/CMDLINE.txt
-
-	# Strip ".md" from the README name.
-	mv $@/README.md.txt $@/README.txt
 	
 	$(TOPLEVEL)/man/simplecpp -D_WIN32 -DPRECOMPILED  \
 	             -D$(shell echo $* | tr a-z A-Z)      \