Convert the rest of the doc files to Markdown.
This commit is contained in:
Mike Swanson
parent
77c680f7d3
commit
e2b4804903
12 changed files with 1413 additions and 1452 deletions
|
|
@ -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,
|
||||
_indentation_ should be four spaces. If possible, do not use tab
|
||||
characters at all. There is a utility called "expand" which will remove
|
||||
You should set tabs to *display* as eight spaces, not four. However,
|
||||
*indentation* should be four spaces. If possible, do not use tab
|
||||
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
|
||||
denotes the subsystem (AM_ for automap, G_ for game, etc). If a
|
||||
Functions should be named like this: `AB_FunctionName`. The `AB` prefix
|
||||
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.
|
||||
I don't care that this isn't standard ANSI C.
|
||||
Use C++-style comments, ie. `//` comments, not `/* ... */` comments.
|
||||
I don’t care that this isn’t standard ANSI C.
|
||||
|
||||
Variables should be named like this: 'my_variable_name', not like this:
|
||||
'MyVariableName'. In pointer variable declarations, place the '*' next
|
||||
Variables should be named like this: `my_variable_name`, not like this:
|
||||
`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)
|
||||
{
|
||||
body;
|
||||
}
|
||||
```c
|
||||
if (condition)
|
||||
{
|
||||
body;
|
||||
}
|
||||
```
|
||||
|
||||
Not this:
|
||||
|
||||
if (condition) // NO
|
||||
body;
|
||||
```c
|
||||
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
|
||||
---------------------------------------------
|
||||
gets() fgets(.., stdin)
|
||||
sprintf M_snprintf()
|
||||
snprintf M_snprintf()
|
||||
vsprintf M_vsnprintf()
|
||||
vsnprintf M_vsnprintf()
|
||||
strcpy() M_StringCopy()
|
||||
strncpy() M_StringCopy()
|
||||
strcat() M_StringConcat()
|
||||
strncat() M_StringConcat()
|
||||
strdup() M_StringDuplicate()
|
||||
Unsafe function | Safer alternative
|
||||
------------------|------------------------
|
||||
`gets()` | `fgets(.., stdin)`
|
||||
`sprintf` | `M_snprintf()`
|
||||
`snprintf` | `M_snprintf()`
|
||||
`vsprintf` | `M_vsnprintf()`
|
||||
`vsnprintf` | `M_vsnprintf()`
|
||||
`strcpy()` | `M_StringCopy()`
|
||||
`strncpy()` | `M_StringCopy()`
|
||||
`strcat()` | `M_StringConcat()`
|
||||
`strncat()` | `M_StringConcat()`
|
||||
`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);
|
||||
sprintf(mybuf, DEH_String("bar %s"), t);
|
||||
```c
|
||||
printf(DEH_String("foo %s"), s);
|
||||
sprintf(mybuf, DEH_String("bar %s"), t);
|
||||
```
|
||||
|
||||
Instead do this:
|
||||
|
||||
DEH_printf("foo %s", s);
|
||||
DEH_snprintf(mybuf, sizeof(mybuf), "bar %s", t);
|
||||
```c
|
||||
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
|
||||
int or int64_t depending on which you want).
|
||||
Do not use the `long` type (its size differs across platforms; use
|
||||
`int` or `int64_t` depending on which you want).
|
||||
|
||||
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
|
||||
ISO C99 data types: intN_t and uintN_t where N is 8,16,32,64.
|
||||
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
|
||||
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
|
||||
if necessary: _WIN32 for Windows and __MACOSX__ for MacOS X. Others
|
||||
Preprocessor `#defines` are set that can be used to identify the OS
|
||||
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
|
||||
(i / (1 << n)). However, most processors handle bitshifts of signed
|
||||
integers properly, so it's not a huge problem.
|
||||
For signed integers, you shouldn’t assume that `(i >> n)` is the same as
|
||||
`(i / (1 << n))`. However, most processors handle bitshifts of signed
|
||||
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 GPL 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 GPLv2 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
|
||||
|
||||
```
|
||||
18
Makefile.am
18
Makefile.am
|
|
@ -39,9 +39,9 @@ CODEBLOCKS_FILES= \
|
|||
|
||||
DOC_FILES= \
|
||||
README.md \
|
||||
README.Music \
|
||||
NEWS \
|
||||
PHILOSOPHY \
|
||||
README.Music.md \
|
||||
NEWS.md \
|
||||
PHILOSOPHY.md \
|
||||
ChangeLog
|
||||
|
||||
EXTRA_DIST= \
|
||||
|
|
@ -49,15 +49,15 @@ EXTRA_DIST= \
|
|||
$(MSVC_FILES) \
|
||||
$(CODEBLOCKS_FILES) \
|
||||
$(DOC_FILES) \
|
||||
NOT-BUGS \
|
||||
README.Strife \
|
||||
NOT-BUGS.md \
|
||||
README.Strife.md \
|
||||
.lvimrc \
|
||||
HACKING \
|
||||
TODO \
|
||||
HACKING.md \
|
||||
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)
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
in the message has downloadable upgrade patches that you can use to
|
||||
upgrade.
|
||||
To fix the problem, you must upgrade your IWAD file, preferably
|
||||
to 1.9. The URL in the message has downloadable upgrade patches that
|
||||
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
|
||||
Messages on/off: F8
|
||||
Graphic detail high/low: F5
|
||||
Screen size smaller/larger: -/+
|
||||
Sound volume menu: F4
|
||||
Option | Key
|
||||
---------------------------|-----
|
||||
End game | F7
|
||||
Messages on/off | F8
|
||||
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
|
||||
buffer overrun".
|
||||
when you save the game, the game will quit with the message “Savegame
|
||||
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
|
||||
disable the "Vanilla savegame limit" option.
|
||||
to be disabled: in the setup tool, go to the “compatibility” menu and
|
||||
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.
|
||||
|
||||
# vim: tw=70
|
||||
|
||||
to buy from Steam or GOG.com.
|
||||
|
|
@ -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
|
||||
gameplay experience can be extended as long as there's a good
|
||||
* 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
|
||||
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
|
||||
Vanilla Doom, because it's useful for portability to machines
|
||||
that don't have a full keyboard.
|
||||
- There are new key bindings for actions that can’t be rebound with
|
||||
Vanilla Doom, because it’s useful for portability to machines
|
||||
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
|
||||
there's a good reason for it. For example:
|
||||
as the defaults match Vanilla, it doesn’t change gameplay and
|
||||
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
|
||||
behavior is to ask the question: "Although this is Vanilla behavior,
|
||||
is there anyone who would want this?".
|
||||
A good litmus test of when it’s acceptable to break from Vanilla
|
||||
behavior is to ask the question: “Although this is Vanilla behavior,
|
||||
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
|
||||
are like Marshmallow Froot Loops; Metacity is like Cheerios.
|
||||
> Boring window manager for the adult in you. Many window managers
|
||||
> 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
|
||||
|
||||
|
|
@ -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
|
||||
configuration dialog in the setup tool, and use the "Timidity
|
||||
configuration file" widget below to enter the path to the Timidity
|
||||
Having installed a sound font, select “Native MIDI” in the sound
|
||||
configuration dialog in the setup tool, and use 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
|
||||
configuration dialog in the setup tool, and use the "GUS patch path"
|
||||
Having downloaded the patches, select “GUS (emulated)” in the sound
|
||||
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-cmipci fm_port=0x388
|
||||
options snd-ymfpci 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:
|
||||
|
||||
|
|
@ -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
|
||||
four years of reverse engineering effort with the blessings of the original
|
||||
programmers of the game.
|
||||
Entertainment’s “Strife: Quest for the Sigil.” It was created through more
|
||||
than four years of reverse engineering effort with the blessings of the
|
||||
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
|
||||
to support it in the future, due to the vast number of differences (the
|
||||
demo version of Strife is based on a much earlier beta version of Rogue's
|
||||
codebase). You should use a commercial Strife IWAD file, preferably of
|
||||
version 1.2 or later.
|
||||
The demo version is *not* supported, and there are not any current plans to
|
||||
support it in the future, due to the vast number of differences (the demo
|
||||
version of Strife is based on an earlier version of Rogue’s
|
||||
codebase).
|
||||
|
||||
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
|
||||
Disables the graphical introduction sequence. -devparm implies this.
|
||||
- -nograph
|
||||
- Disables the graphical introduction sequence. -devparm implies this.
|
||||
|
||||
-novoice
|
||||
Disables voices even if voices.wad can be found.
|
||||
- -novoice
|
||||
- Disables voices even if voices.wad can be found.
|
||||
|
||||
-work
|
||||
Enables Rogue's playtesting mode. Automatic godmode, and pressing the
|
||||
inventory drop key will toggle noclipping.
|
||||
- -work
|
||||
- Enables Rogue’s playtesting mode. Automatic godmode, and pressing the
|
||||
inventory drop key will toggle noclipping.
|
||||
|
||||
-flip
|
||||
Flips player gun graphics. This is buggy, however, because it does not
|
||||
reverse the graphics' x offsets (this is an accurate emulation of the
|
||||
vanilla engine's behavior).
|
||||
- -flip
|
||||
- Flips player gun graphics. This is buggy, however, because it does not
|
||||
reverse the graphics’ x offsets (this is an accurate emulation of the
|
||||
vanilla engine’s behavior).
|
||||
|
||||
-random
|
||||
Randomizes the timing and location of item respawns in deathmatch, when
|
||||
item respawning is enabled.
|
||||
- -random
|
||||
- Randomizes the timing and location of item respawns in deathmatch, when
|
||||
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.
|
||||
|
||||
|
|
@ -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
|
||||
- Use size-specific types (eg. int32_t instead of int)
|
||||
- Don't make structure packing assumptions when loading levels.
|
||||
- Test on and fix for architectures where `((-2) >> 1) != -1`
|
||||
- Use size-specific types (eg. `int32_t` instead of int)
|
||||
- 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
|
||||
|
||||
|
|
@ -19,8 +19,8 @@ PACKAGE_VERSION = @PACKAGE_VERSION@
|
|||
|
||||
# Documentation files to distribute with packages.
|
||||
|
||||
DOC_FILES = README.md \
|
||||
README.Music \
|
||||
COPYING \
|
||||
NEWS
|
||||
DOC_FILES = README.md \
|
||||
README.Music.md \
|
||||
COPYING \
|
||||
NEWS.md
|
||||
|
||||
|
|
|
|||
|
|
@ -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)"
|
||||
|
|
|
|||
|
|
@ -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 \
|
||||
cp $(TOPLEVEL)/$$f $@/$$f.txt; \
|
||||
for f in $(DOC_FILES); do \
|
||||
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) \
|
||||
|
|
|
|||
Loading…
Reference in a new issue