| Age | Commit message (Collapse) | Author |
|---|
|
Removed nonexistent files
|
|
|
|
The preferences for the OS X launcher are currently stored in a file
ambiguously named "launcher.plist" that could conflict with any other
app on the system that chose to use the same moniker. Use the more
specific identifier of org.chocolate-doom.launcher to avoid conflicts.
Also set NSHumanReadableCopyright so that we get more detail on the
"About" window in the launcher app.
This fixes #570. Thanks to Xeriphas1994 for the suggestion to tweak
the identifier.
|
|
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 legal status is a lot clearer now that Strife: Veteran Edition has
been released. Remove the "New in v2.0 Release" section as this is
unlikely to be kept up to date, and these updates are covered by the NEWS
file that serves this purpose.
|
|
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.
|
|
Since the addition of OPL3 support, compile of opl_sdl.c generates a
warning because the declaration of Chip__GenerateBlock3() was not added
to dbopl.h.
|
|
In the Windows scenario we don't need to allocate any buffers; it's
just a thin wrapper around ShellExecute().
|
|
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!
|
