| Age | Commit message (Collapse) | Author |
|---|
|
Now matches the default Chocolate Doom gamepad bindings, switches next
weapon to previous weapon so regular shotgun and fists are selectable
|
|
|
|
|
|
I emailed Richard Hughes about what I interpreted in the spec as a
requirement that images be in 16:9 aspect. He corrected me by saying
that arbitrary dimensions are allowed, the software center will do the
padding on its own.
|
|
This should resolve #406; the description text probably needs
revisement, and we still need to compose images for the screenshots
section.
|
|
|
|
The game is sold on GOG.com now for the Windows platform. This should
add support for finding the IWADs installed through it.
I've repurposed the Collector's Edition functions for this, the basic
principle for finding the directories is the same between the two, and
it keeps the code duplication low.
resolves #600
|
|
Clang defines __GNUC__ but does not support the gnustruct packing
attribute, so add some extra #ifdef checks to catch Clang.
|
|
The XDG Base Directory Specification defines standard directories
that are searched for data files via the XDG_DATA_HOME and
XDG_DATA_DIRS environment variables:
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
To make Chocolate Doom a good citizen, use these directories to
determine some of the locations in which to look for IWAD files. This
includes /usr/share/games/doom, which is absorbed under the default
value of the XDG_DATA_DIRS variable. We also now support the alternative
~/.local/share/games/doom as a user-writeable path in the user's home
directory that doesn't require root privileges.
This is part of #597 (thanks to @chungy for the suggestion).
|
|
GCC fails to properly pack structs although they are tagged with
__attribute__((__packed__)) if called with -mms-bitfields which has
become the default on Windows at some point:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991
|
|
|
|
gametic and singletics are defined in d_loop.c, but there were still
some duplicate definitions of these variables left over from before
the game code was factored out.
This fixed #561 (thanks edward-san).
|
|
Integer overflow is undefined and this breaks when using Clang with
-O2 optimization turned on. This fixes #572 (thanks to David Majnemer
for insight into fixing this bug).
|
|
|
|
|
|
The help URL for the warp menu was linking to the multiplayer start
game menu.
|
|
The warning message would have been missed by anyone not running from
the console (ie. a good portion of all Windows and Mac users), so
replace the warning message with an error instead (I_Error calls
produce a GUI message popup). Allow this behavior to be overridden by
using a special command line flag.
|
|
This no longer returns a boolean value, but actually returns an
integer indicating the type of OPL chip that was detected. Change
the return value to have a more meaningful value.
|
|
Vanilla Doom used the DMXOPTION environment variable to control
whether OPL3 output was generated. Emulate this, and use a config
file variable that can set DMXOPTION without needing to configure
it via an environment variable.
|
|
1bcff874c52a changed the behavior of P_RunThinkers() to avoid
dereferencing thinker pointers after they had been freed, but the
modified version of the function was not logically equivalent to
Vanilla version, because the 'next' pointer can be changed by the
thinker function if one is invoked.
This fixes a desync in tnt-speed-movie-0443131.lmp. Thanks to Zvonimir
Bužanić for the bug report and Fabian Greffrath for reporting.
Fixes #547.
|
|
This actually (I believe) fixes three separate issues that are all
aspects of the same bug:
* Alexandre-Xavier reported that when running at full framerate, the
single -devparm dot would flash (#374);
* Linguica reported on Doomworld that Chocolate Doom appeared to be
rendering each tic twice (see:
http://www.doomworld.com/vb/post/1340374 ).
* Harha reported performance problems when running in a VM, which
may be related (http://www.doomworld.com/vb/post/1374315 ).
Chocolate Doom long ago (41cdd5785305a) changed the main loop code so
that it does not freeze in network games when tics stop being
received; the idea is that it should always be possible to activate
the menu to quit. Vanilla Doom allows this too, but only after 20 tics
of waiting in TryRunTics() for network data to be received; the menu
can be used but is deathly slow. So the loop was changed to wait for
only 1 tic instead.
However, there was an error in the logic for the check. In a single
player game, when time has advanced to the point of being ready to
execute another tic, NetUpdate() will build the new ticcmd_t;
TryRunTics() was returning immediately; according to the timer, at the
exact same time as tic generation, we had also been spinning in the
loop for a whole tic and it was time to render a new frame.
The end result was that each tic transition would trigger two frames
to be rendered: the previous frame, and the new frame. Clearly this is
not what is intended.
To fix the problem:
* Refactor the blocking loop in TryRunTics() so that we only bail out
of the function after checking that the loop's exit condition has
not just been satisfied (also to eliminate an unnecessary call to
I_Sleep() between ticcmd_t generation and execution).
* Increase the delay before we bail out to 5 tics rather than just 1.
This is still much less than the 20 used in Vanilla Doom but is
low enough to keep the menu responsive. A higher bar should ensure
that this bug can't reoccur, even in multiplayer where the clocks
can be adjusted for sync.
This fixes #374. Thanks to everyone involved in reporting the different
aspects of it.
|
|
The other windows all have help links now and the multiplayer
windows were the only ones left without them, so this adds links
for them. For now these just link to the wiki's Multiplayer page
but this is something we can change in the future.
This is part of #520.
|
|
|
|
|
|
I previously tweaked the voice replacement algorithm, but after
listening to the MAP01 music in DOSbox, this does indeed seem to be
how the music sounds in Vanilla Doom.
|
|
Formatting, variable names, don't pollute global variable namespace.
|
|
Older DMX's OPL voice allocation algorithm
|
|
Prefer replacing a second voice before a voice from a higher-
numbered channel. This resolves some issues with the MAP01 music,
as noted in comments on #468; it may not be Vanilla behavior in
terms of code but seems to better match it based on observation,
and makes logical sense.
Also adjust code to fit to the 80 column limit.
|
|
|
|
|
|
fixes #511
|
|
This might seem presumptuous but is actually legitimate. The version
of sha1.c here is derived from cipher/sha1.c from the GnuPG 1.4 stable
branch in 2012. Since October 2007, all GnuPG releases have been made
under the GPLv3, but the earlier releases were under GPLv2 and there
do not appear to have been any changes to sha1.c between 2007 and
2012. So the same file was previously released under the GPLv2.
The relevant commit from the GnuPG Git repository is 9a2a818887b4d36c;
this commit is essentially a revert of the part of that commit that
applies to cipher/sha1.c.
This fixes #479.
|
|
The id Anthology version of doom2.exe with Final Doom fixed the "Sky
never changes in Doom II" bug. The original Doom source release
included the repaired code, but it was re-bugged in an early Chocolate
Doom version to emulate the behavior of the better-known versions of
vanilla.
Thanks to @fabiangreffrath for demonstrating how he (more-generically)
fixed the bug in Crispy Doom.
Closes #533
|
|
The old AES implementation was from GnuPG, which is GPLv3 and not
compatible with Chocolate Doom's GPLv2 license. Switch to the
implementation of AES found inside the Linux kernel instead.
This fixes #479, #507.
|
|
|
|
This was removed back in d190b596c566394717324296cbf6b46e67c64f5c;
at the time I didn't understand what it was or how it was supposed
to be used - it seemed like cruft left over from Doom's development.
It is actually a potentially useful feature for level authors when
developing their maps. See here: http://doomwiki.org/wiki/Reload_hack
The reload hack is a relatively obscure feature of limited usefulness
nowadays, but nonetheless a technical curiosity that ought to be
preserved in Chocolate Doom.
The reimplementation here is a lot cleaner than the original version
from the source release: W_Reload() is based on a call to W_AddFile(),
we don't reopen the reload file every time we want to read a lump,
and we include a check in W_AddFile() that we are not trying to use
the hack on more than one PWAD file.
This fixes #539.
|
|
Fixed by commenting out the reported variables and their settings
instead of removing them. Since I am not sure if they were added by
mistake or by purpose and then overseen, I think it's better to keep
them in the code but not compile them in for now.
|
|
The "extern char player_names[8][16]" array is already declared in
hu_stuff.h:59.
|
|
These were caused by loops which caused overflow of variables of type
angle_t (= unsigned) by multiplication with iterators of typed int in
angle calculations. Changing the type of the iterator variables to
"unsigned int" prevents the undefined behavior.
|
|
Actually, it was already impossible for the reported variables to be
used uninitialized, because they were all assigned a value by calling
ReadByte() and the function would return if that failed. However, the
compiler couldn't know about this fact, so we do him the favor and
initialized them to 0.
|
|
The Hexen demo IWAD is "detected" as v1.0 because it's missing the
same lumps that the commercial v1.0 IWAD is missing, but we don't
want to show the warning message if we're playing the demo; it is
supported.
|
|
The Hexen v1.0 IWAD file differs too much from the v1.1 IWAD file and
can't be reasonably supported by us. Show a warning message on startup
if the user appears to be trying to play using the v1.0 IWAD file.
This fixes #537.
|
|
Remove a redundant check from an ORer condition. Unlike in Doom, in
Hexen the player->message element is not a pointer, but a char[80]
array. Its address will never be NULL and thus will never get
interpreted as "false". Hence, the check for "!player->message" will
never be "true" and a check for "|| false)" is a no-op.
Thanks to @edward-san for finding this with clang-3.6!
|
|
This fixes warnings that are caused by calling GET_LONG without using
its return value, e.g.:
sv_save.c: In function ‘StreamIn_player_t’:
../../src/i_swap.h:34:20: warning: value computed is not used [-Wunused-value]
#define LONG(x) ((signed int) SDL_SwapLE32(x))
^
sv_save.c:33:18: note: in expansion of macro ‘LONG’
#define GET_LONG LONG(*SavePtr.l++)
^
sv_save.c:349:5: note: in expansion of macro ‘GET_LONG’
GET_LONG;
^
Introducing a "long dummy" variable and calling "dummy = GET_LONG" does
not help, because this provokes another warning, rightfully so:
sv_save.c: In function ‘StreamIn_player_t’:
sv_save.c:346:10: warning: variable ‘dummy’ set but not used [-Wunused-but-set-variable]
long dummy;
Assigning the return value directly to the struct field results in:
sv_save.c: In function ‘StreamIn_player_t’:
sv_save.c:349:13: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
str->mo = GET_LONG;
Adding the cast to "(void *)" results in:
sv_save.c: In function ‘StreamIn_player_t’:
sv_save.c:349:15: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
str->mo = (void *) GET_LONG;
Adding the intermediate cast to "(intptr_t)" finally silences the
compiler. Phew!
|
|
|
|
This fixes the following two warnings
cast from pointer to integer of different size
cast to pointer from integer of different size
by either changing some ints that are supposed to hold pointers
to intptr_t type or by intermediate casting to (intptr_t).
|
|
When using the -playdemo parameter, we support a convenience feature
where the .lmp extension is not appended if it is already part of the
filename. This makes tab completion much nicer. But if the .lmp file
has a filename that is in all-caps (.LMP) we were still appending the
extension because the check was case sensitive. Change the check to
be case insensitive.
This fixes #501 (thanks Ioan Chera).
|
|
|
|
When an mobj_t is freed, any currently-playing sounds attached to that
object are stopped, but the sound code was leaving a dangling pointer
to the freed mobj_t that was flagged by the -zonescan checks.
|
|
As further tooling to help debug bugs like #530, add a command line
parameter that will scan the zone heap every time a block of memory
is freed with Z_Free(), to detect dangling pointers to the freed
block.
|
