Commit 4e19dd19 authored by Jonathan Dowland's avatar Jonathan Dowland

Import Upstream version 5.0+dfsg1

Thanks for contributing to Chocolate Doom! Whatever your contribution,
whether it's code or just a bug report, it's greatly appreciated.
The project is governed by the
[Contributor Covenant](
version 1.4. By contributing to the project you agree to abide by its
terms. To report violations, please send an email to
### Reporting bugs
Before reporting a bug, it's worth checking if this really is a bug.
Chocolate Doom's mission is to reproduce the Vanilla (DOS) versions of
the Doom engine games, bugs and all. Check out the
[NOT-BUGS](../ file for a list of common issues which aren't
really bugs at all. You might also try searching [the GitHub issues
list]( to see
if your bug has already been reported.
If you're confident that you've found a real bug (or even if you're
not sure!) please go ahead and [file an issue on
You'll need a GitHub account, but it's pretty easy to sign up.
Please try to give as much information as possible:
* What version of Chocolate Doom are you using? Check the title bar of
the window for the version number.
* Chocolate Doom runs on many different operating systems (not just
Windows!). Please say which operating system and what version of it
you're using.
* Please say which game you're playing (Doom 1, Doom 2, Heretic,
Hexen, Strife, etc.) and list any add-on WADs you're using. Please
mention if you have any special configuration you think may be
relevant, too.
### Feature requests
Chocolate Doom is always open to new feature requests; however, please
be aware that the project is designed around a deliberately limited
[philosophy](../, and many features common in other source
ports will not be accepted. Here are a few common requests which are
often rejected:
* "High resolution" rendering (greater than 320x200 display).
* An option to disable Vanilla limits, such as the visplane rendering
* Ability to play "No Rest For The Living", the expansion pack which
comes with the XBLA / BFG Edition of Doom.
If you're not sure whether your feature is in line with the project
philosophy, don't worry - just ask anyway!
To make a feature request, [file an issue on
### Bug fixes / code submission
Thank you for contributing code to Chocolate Doom! Please check the
following guidelines before opening a pull request:
* All code must be licensed under [the GNU General Public License,
version 2](
Please don't reuse code that isn't GPL, or that is GPLv3 licensed.
Be aware that by submitting your code to the project, you're agreeing
to license it under the GPL.
* Please follow the coding style guidelines described in the
[HACKING](../ file.
* Please don't make unnecessary changes which just change formatting
without any actual change to program logic. While being consistent
is nice, such changes destroy the ability to use the `git blame`
command to see when code was last changed.
* The guidelines given above in the "feature requests" section also
apply here. New features which aren't in line with the project
philosophy are likely to be rejected. If you're not sure, open a
feature request first and ask before you start implementing your
* Follow the guidelines for [how to write a Git commit
message]( In short: the
first line should be a short summary; keep to an 80 column limit;
use the imperative mood ("fix bug X", rather than "fixed bug X" or
"fixing bug X"). If your change fixes a particular subsystem,
prefix the summary with that subsystem: eg. "doom: Fix bug X" or
"textscreen: Change size of X".
* If you're making a change related to a bug, reference the GitHub
issue number in the commit message, eg. "This is a partial fix
for #646". This will link your commit into the issue comments. If
your change is a fix for the bug, put the word "fixes" before the
issue number to automatically close the issue once your change
is merged.
# These are the default patterns globally ignored by Subversion:
# Ignore GNU Global tags and html files
" Local vimrc configuration file. Install the localvimrc.vim vim script.
set expandtab
set tabstop=8
set softtabstop=4
set shiftwidth=4
" Add all tag files to tags path.
let topdir = findfile("", ".;")
let topdir = substitute(topdir, "", "", "")
" Check tags file in current dir:
set tags+=tags
" Add tag files in parent directories:
let tagfiles = findfile("tags", ".;", -1)
" Add tag files for libraries:
call add(tagfiles, topdir . "opl/tags")
call add(tagfiles, topdir . "pcsound/tags")
call add(tagfiles, topdir . "textscreen/tags")
for tagfile in tagfiles
" Don't go beyond the project top level when adding parent dirs:
if stridx(tagfile, topdir) >= 0
exec "set tags+=" . tagfile
unlet topdir
unlet tagfiles
set -e
if [ "$ANALYZE" = "true" ] ; then
cppcheck --error-exitcode=1 -j2 -UTESTING -Iopl -Isrc -Isrc/setup opl pcsound src textscreen > /dev/null
make install DESTDIR=/tmp/whatever
make dist
language: c
compiler: gcc
# Travis uses Ubuntu 12.04 (Precise) for builds by default, which is too
# old and missing the SDL2 packages, so use Trusty instead.
sudo: required
dist: trusty
- ANALYZE=false
- ANALYZE=true
- cppcheck
- libsdl2-dev
- libsdl2-mixer-dev
- libsdl2-net-dev
- libsdl2-image-dev
- libsamplerate0-dev
script: ./
- master
- sdl2-branch
Simon Howard <>
James Haley <>
Samuel Villarreal <>
Fabian Greffrath <>
Jonathan Dowland <>
Alexey Khokholov <>
# Contributor Covenant Code of Conduct
## Our Pledge
In the interest of fostering an open and welcoming environment, we as
contributors and maintainers pledge to making participation in our project and
our community a harassment-free experience for everyone, regardless of age, body
size, disability, ethnicity, gender identity and expression, level of experience,
nationality, personal appearance, race, religion, or sexual identity and
## Our Standards
Examples of behavior that contributes to creating a positive environment
* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members
Examples of unacceptable behavior by participants include:
* The use of sexualized language or imagery and unwelcome sexual attention or
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic
address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting
## Our Responsibilities
Project maintainers are responsible for clarifying the standards of acceptable
behavior and are expected to take appropriate and fair corrective action in
response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove, edit, or
reject comments, commits, code, wiki edits, issues, and other contributions
that are not aligned to this Code of Conduct, or to ban temporarily or
permanently any contributor for other behaviors that they deem inappropriate,
threatening, offensive, or harmful.
## Scope
This Code of Conduct applies both within project spaces and in public spaces
when an individual is representing the project or its community. Examples of
representing a project or community include using an official project e-mail
address, posting via an official social media account, or acting as an appointed
representative at an online or offline event. Representation of a project may be
further defined and clarified by project maintainers.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported by contacting the project team at All
complaints will be reviewed and investigated and will result in a response that
is deemed necessary and appropriate to the circumstances. The project team is
obligated to maintain confidentiality with regard to the reporter of an incident.
Further details of specific enforcement policies may be posted separately.
Project maintainers who do not follow or enforce the Code of Conduct in good
faith may face temporary or permanent repercussions as determined by other
members of the project's leadership.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
available at [][version]
This diff is collapsed.
Chocolate Doom's version history is stored in Git. For a full
change log, clone the repository on Github:
# 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
the program, and does not require the original code to be changed. Some
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
tab characters. For the reasoning behind this, see:
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
function is static, you can omit the prefix and just name it like
`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
should be all lowercase and have the subsystem name at the start. An
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.
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)
Not this:
if (condition) // NO
Write code like this:
typedef struct
int member1;
char *member2;
} my_structure_t;
void FunctionName(int argument, int arg2, int arg3, int arg4, int arg5,
int arg6, int arg7)
int assign_var;
assign_var = arg2 + arg3 * arg4 * (arg5 + arg6);
if (foo && !bar || baz && qux || !(foo && bar && baz))
else if (xyz + 4 < abc * 4 + 3)
if (very_long_condition_like_this_one_that_forces_a_line_break
&& other_condition)
switch (argument)
case FIRST:
case SECOND:
for (a = 0; a < 10; ++a)
FunctionCall(arg1, arg2, arg3, arg4,
while (a < 10)
} while (condition);