| Age | Commit message (Collapse) | Author |
|---|
|
|
|
allow -geometry to specify fullscreen or windowed modes, like PrBoom
|
|
Chocolate Doom isn't hosted on Sourceforge any more.
|
|
|
|
|
|
during the initialization instead of a hard-coded diversion in the
options menu itself
|
|
The main purpose for this parameter is to allow mods made for the Final
Doom IWADs to be played properly with Freedoom. Chocolate Doom detects
mission packs (pack_tnt/pack_plut) based on the file name. However, the
Freedoom: Phase 2 IWAD contains the textures for all three Doom2-format
IWADs, so can be used to play MegaWADs like Plutonia 2 that were
designed to be played with plutonia.wad.
Because mission pack detection is done based on filename, freedoom2.wad
is handled the same as doom2.wad (a sensible default). But this means that
when playing using a mod like Plutonia 2, the wrong level name is shown
on the automap screen (along with eg. intermission text). To fix this we
need a way to manually override the mission pack. -pack allows this to
be done. It's kind of tedious that this has to be done manually but at
least it can be done.
Thanks chungy for the bug report/suggestion. This fixes #449.
|
|
|
|
When using the -cdrom command line parameter (does anyone still use
that?), savegames should be written to c:\doomdata to properly
reproduce Vanilla behavior. These were being incorrectly written to
c:\doomdata\savegames\foo.wad instead.
This fixes #175. Thanks Alexandre-Xavier.
|
|
If a Unicode character is not part of the Extended ASCII set that
we can display on screen, don't allow it to be typed (which would
display a backwards question mark). Thanks Alexandre-Xavier for this
suggestion on #229.
|
|
`else if (f == 'w')` doesn't really secure itself against
uninitialized memory, it still needs to test that `s == 3`.
|
|
This allows strings like "640x480w" to cause the engine to run in a
window, while strings like "1280x800f" cause the engine to run in
fullscreen mode. This is inspired by the behavior of the PrBoom
-geometry parameter.
|
|
|
|
When playing using one of the Freedoom IWADs, set the gamedescription
string to be the full title of the IWAD being played, rather than
showing "Ultimate Doom" or "Doom II: Hell on Earth" etc.
This fixes #446 (thanks chungy).
|
|
The order in which we load dehacked patches is important. Change the
order so that IWAD dehacked patches are loaded before any others, and
so if, for example, we're playing with Freedoom, the Freedoom string
replacements can be overridden by those from extra mods we're playing
with.
As part of this, ditch DEH_Init() and use DEH_ParseCommandLine()
instead to handle the -deh option. Remove the DEH_Init() message
from startup and show messages about dehacked patches that we load
with the WAD files that we load.
|
|
If loading two dehacked patches and both replace the same string,
the second replacement should override the first. Change the API
function DEH_AddStringReplacement so that the from_text and to_text
are implicitly duplicated, and we can free to_text and replace
it later if we subsequently change it to something else.
|
|
As per suggestions from Fabian Greffrath:
* Change -noiwaddeh to -nodeh for consistency with other source ports
(Boom-derived source ports use this to disable loading of DEHACKED
lumps).
* Extend the parameter so that it also disables loading of the Chex
Quest dehacked patch.
* Refactor the code for loading IWAD dehacked patches to all be in a
single function.
|
|
Both the Freedoom IWADs and the rereleased HACX IWAD contain embedded
DEHACKED lumps that are automatically loaded on startup. However,
there may be some situations where it is undesirable to load these
patches - when loading certain mods such as BTSX, for example. For
these cases, allow the user to override the default behavior with a
command line parameter.
|
|
Hopefully this may fix issue where exe very occasionally continues to
run in background after exit. See chocolate-doom/chocolate-doom#408.
Conflicts:
src/i_system.c
|
|
This fixes #442, a crash caused by adding a new WAD file after a
lump has been loaded (and cached) from a previous WAD. This
manifested when playing using the Freedoom IWADs and also loading
a PWAD at the same time. The Freedoom IWADs have DEHACKED lumps
that are loaded from within the IWAD file.
The ultimate cause (thanks to Fabian Greffrath for uncovering it)
is that lumpinfo is realloc()ed after each new WAD load to store
the lumpinfo_t structures from the new WAD. If a lump has been read
and cached from a previous WAD file, it may end up having an invalid
'user' pointer that points to somewhere in the old lumpinfo[] array,
not the new one.
I think this bug was masked because realloc() will often not move
data if the previous location can simply be extended. The bug was
discovered when loading BTSX as a PWAD, probably because it's a
large WAD that contains a lot of lumps, and forced a move during
realloc.
|
|
It turns out that the way that tempo has been calculated in OPL playback
has been broken for a long time. The mysterious "fudge factor" that I
had to apply to tempo calculations is actually completely unnecessary:
the byte-swapping in the MIDI_GetFileTimeDivision() function was being
done wrong, so the time division being used by the OPL MIDI code was
completely wrong. Presumably the multiply by 260 was close enough to an
8-bit bitshift that it worked okayish, but large enough time division
values would overflow a single byte and screw up.
This fixes long-running OPL playback problems in a number of WADs, most
notably Alien Vendetta. This *really* fixes #352.
|
|
When propagating mouse button presses to widgets within the window,
return from MouseButtonPress() immediately, or we will fall through
to additional code that references the window structure. If the
handler for the widget we clicked on closes the window, this will
have been freed.
This fixed #439. Thanks to DuClare for telling me about this.
|
|
Vanilla Doom's -warp parameter allows warping to episodes beyond E4.
This didn't work in Chocolate Doom because of some changes made
to the G_InitNew code before the source release. Actual decompilation
of that function in Vanilla Doom shows that the episode/map sanity
checking is not present:
http://pastie.org/8140437
There is at least one known WAD (2002ado) that has a map on E5M1
that is playable in Vanilla, and this stops that map from being
possible to play. Comment out that code because it obviously
doesn't deserve to be there.
This fixes #426. Thanks plumsinus.
|
|
A message is printed if you are playing a game using the old sync
code, which could put you at a disadvantage compared to other players.
Disable this message for now as we're defaulting to old sync for the
time being.
|
|
The new netgame client sync code has the potential to be much better
than the original sync code. However, it currently has a buggy
controller and needs revisiting and overhauling (#358).
For the time being, switch back to the old sync code by default and
allow the new code to be enabled using the -newsync parameter
(replacing the -oldsync parameter).
|
|
The Doom II MAP14/MAP20 music has a hanging note at the end of the
track that is never turned off. If this is not reset when the track
loops, there is a continuous (and annoying) drone sound throughout
the next iteration of the song. Some information is here:
http://www.doomworld.com/vb/source-ports/66802-the-d-ddtblu-disease/
This changes the mus2mid code to generate an "all notes off"
controller event at the start of the MIDI track. This is specifically
done at the start and not the end of the track because otherwise the
looping of tracks like D_RUNNING is affected.
Thanks to a whole host of people for help on this: @plumsinus for
reporting the bug, @bradharding for devising a fix as part of Doom
Retro, and Quasar for feedback and his own fix to the Eternity Engine.
This fixes #412.
|
|
Previous revamping of the OPL library changed delay times from ms
to us, and switched to 64-bit times for storage for them. However
this type change was botched and some functions were still using
32-bit arguments. Change to 64-bit types.
Thanks Quasar for reporting this. This fixes #438.
|
|
For the Hexen substitute mapping configuration file, it's desirable
to be able to include two mappings for each music lump: a straight
high quality recording of that lump, and the recording that was
included on the Hexen CD audio tracks. So allow multiple mappings
so that we can fall back to try other filenames if the first choice
file doesn't appear to exist.
|
|
fixes #428
|
|
|
|
The Mac version of hexen.wad is slightly different from the normal
DOS one: it contains a bunch of extra lumps but more importantly,
the GENMIDI and DMXGUS lumps are missing. This means that Chocolate
Hexen would crash on startup with the default settings (as OPL is
the default music output).
To work around this problem and allow the game to start up properly,
detect if the required lump is missing and adjust the music settings,
printing a helpful message to stdout to inform the user.
|
|
Use of the wrong enum value as an index into weaponinfo left the
torpedo's selectability accidentally relying on you having 30 or more
rockets instead of cells. Verified against binary as a choco error.
|
|
First sector moved instantly for buildDown16 stairs due to neglect of
using direction instead of constant 1. Also found that Strife clears the
tag of the first stair sector.
|
|
Was not propagating properly from player to beacon to rebels due to
mistranslated assembly code; access to wrong structure.
|
|
|
|
|
|
It was pointed out to me recently that vldoor_e has enum values
named 'open' and 'close'. These can potentially conflict with POSIX
standard functions that have the same names, if the right header
files are included.
This doesn't currently cause any problems. However, to avoid any
possibility of a conflict occurring if a different compiler is used,
add a vld_ prefix to all the enum values, to namespace them.
|
|
If using one of the Freedoom IWADs, detect it by checking for the
FREEDOOM lump, and then load its DEHACKED lump to apply the
cosmetic string changes that it includes. In case we're using an old
version of one of the Freedoom IWADs, don't bomb out with an error
while parsing the DEHACKED lump.
|
|
Magic comments allow some of the Vanilla limits to be overridden, but
they should only apply to the files in which they were defined. Reset
the flag variables that control these overrides before every new
Dehacked file is parsed, so that a flag set in one file cannot spill
over into other files that are parsed subsequently.
|
|
The Dehacked code must pass a special flag to DEH_ReadLine() when
parsing the [STRINGS] section, so that lines can be escaped onto
following lines. However, this flag value was calculated incorrectly.
The BEX [STRINGS] section cannot be looked up at the start of
parsing a Dehacked file, because GetSectionByName() will return
NULL for it (extended strings are not available yet). Instead,
simplify the logic to look at the name of the current section and
check that way.
|
|
Boom added an alternate method for overriding Dehacked strings, using
the [STRINGS] section with special symbolic names for each of the
strings that can possibly be replaced.
This format is used in the Freedoom DEHACKED lump (deliberately, so
that the Freedoom WAD does not include the original text to be
replaced). As we want to have support for the Freedoom IWADs with
Chocolate Doom, add support for the BEX [STRINGS] section, but
protected by a magic comment that must be included in Dehacked/BEX
files that use it.
Thanks to Fabian Greffrath for implementing this.
|
|
|
|
- restructure DEH_ReadLine() to avoid use of "goto"
- bex_string_t type name ends in "_t"
- declare constant table as "static const"
- add magic comment *allow-extended-strings* and corresponding
variable deh_allow_extended_strings
- fix logical error when no [STRINGS] section is registered to which
corrent_section could be compared
|
|
|
|
Update setup.vcproj
|
|
Need to include the missing files in the setup project: txt_joyaxis.h and txt_joyaxis.c.
Without this, setup won't compile, complain about unresolved external symbol.
|
|
The Buffalo Classic USB Gamepad is a USB gamepad that resembles the
classic SNES controller. Thansk to Fabian Greffrath for sending in
the report.
|
|
Thanks to "Absolute Zero" for the report with the gamepad settings.
|
|
|
|
The XBOX One controller apparently appears identical to the Xbox
360 controller. Thanks Brad Harding.
|
