| Age | Commit message (Collapse) | Author |
|---|
|
textscreen: use ShellExecute on Windows to open URLs
|
|
|
|
Trying to use the cmd.exe built-in has been causing nothing but
troubles, this is the officially supported way to open them.
|
|
Alexandre-Xavier commented in #520 that the 'start' command line to
open help URLs doesn't work. According to this page, 'start' is
actually a cmd.exe built-in and can't be shelled out to directly:
http://www.dwheeler.com/essays/open-files-urls.html
This prepends cmd /c to the 'start' command; hopefully this should
work. It might still be non-ideal if it causes a cmd.exe window to
briefly pop up; in the long term we should probably switch to the
ShellExecute() API function instead.
|
|
|
|
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.
|
|
Tweaks to the Strife notes based on feedback from Quasar, and add
mention of the OPL3 support now that it has been merged.
|
|
|
|
opl: Add OPL3 mode.
The DMX library had limited support for the features of the OPL3 chip,
enabled by setting the DMXOPTIONS variable. This reproduces the OPL3
support in Chocolate Doom's OPL playback and emulation layer.
Huge thanks to Alexey Khokholov for researching and developing this.
This fixes #470.
|
|
|
|
|
|
|
|
|
|
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.
|
|
doom: the sky changes in final2 map11->12 and map20->21 transitions.
|
|
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.
|
|
As seen in bug #530, some of the game code can in some situations hold
pointers to, and dereference, freed sections of the zone heap. Add a
new command line parameter that zeroes out memory of blocks when they
are freed with Z_Free(), hopefully exposing code that depends on
reading freed memory.
|
|
Save the next pointer in the P_RunThinkers() loop when iterating through
thinkers, so that if the current thinker is freed we can still advance
to the next thinker without dereferencing freed memory.
|
|
|
|
This file is empty and contains no code, as it was factored out into
the common m_misc.c during raven-branch development. The Heretic
version got removed once it was empty but the Hexen one wasn't, for
some reason.
|
|
Chocolate Doom fails to properly parse the last line in DEHACKED files
that are missing a newline character at the end of the file (which
might have been a common sickness to DOS editors).
This is, because DEH_GetChar() returns -1 at EOF and DEH_ReadLine() in
turn immediately returns NULL if the result of (DEH_GetChar() < 0),
regardless of the content of the readbuffer. It only returns a pointer
to the content of the readbuffer if DEH_GetChar() returns '\n' which
is, however, impossible if there is no such character before the file
ends.
Now DEH_ReadLine() only returns NULL if the readbuffer is empty at the
end of the file and returns a valid pointer else.
Fixes #531
|
