| 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
|
|
|
|
This is not the complete news for changes since 2.2, just what will be
included for the stable release.
|
|
This is based on a patch proposed for libvirt:
https://www.redhat.com/archives/libvir-list/2010-February/msg00863.html
Fixes #604
|
|
|
|
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.
|
|
We now search in a bunch of different directories in order to find
IWAD files to use to play with, and the logic is a bit complicated.
Add some hopefully friendly documentation to explain where people
can put their IWAD files to play with.
Part of #597.
|
|
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).
|
|
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.
|
|
|
