| Age | Commit message (Collapse) | Author |
|---|
|
opl note limitation and octave overflow fixes
Adjust how the OPL MIDI code behaves at extreme MIDI note values
(high/low octaves) to better match how the Doom DMX library decides
on the OPL register value (thanks Alexey Khokholov / khokh20010.
|
|
opl additive voice volume calculation fix
Adjust how the OPL volume register values are calculated based on the
channel, note and global MIDI volume, to better match how the Doom
DMX library performs these calculations (thanks Alexey Khokholov /
khokh2001).
|
|
|
|
MIDI uses channel 9 for percussion but MUS uses channel 15. As the
channel numbers matter when we run out of free voices (#468),
internally swap channels 9 and 15 so that channel precedence is
decided correctly.
|
|
And yes I double checked the commit target this time.
|
|
* Grid is not supported and gives no such message
* Spot marking is substantially different
|
|
This reverts commit 12ecb4550e46ffdc28248be185738a88be033afd.
|
|
* Grid is not supported and gives no such message
* Spot marking behavior is substantially different
|
|
opl additive voice volume calculation fix
|
|
|
|
Fix voice allocation when there are no more free voices. This fixes a
long-standing (but minor) discrepancy between the OPL code and the DMX
library that was marked in the code with a TODO.
|
|
opl voice allocation fix when there are no free voices
|
|
fixed note drum instrument should be 60
|
|
|
|
opl additive voice volume calculation fix
|
|
With the addition of the Freedoom IWADs, the number of IWADs supported
by chocolate-doom has been raised to 10. However, the iwad_labels[]
array only holds place for up to 8 pointers. Incidently, I have all 10
IWADs installed and trying to warp into a game from
chocolate-doom-setup leads to an out-of-bounds access of this array
and so the application crashes with a segmentation fault.
Instead of increasing the array size to 10, which will bite us next
time, I decided to set its size dynamically as soon as the number of
IWADs of known.
|
|
Resolves #196
|
|
Resolves #433
|
|
Flag to be cleared is MF_SPECIAL, not MF_SOLID (verified against
disassembly). Otherwise you get to spawn an infinite number of rebels
from one beacon. Not to mention, it isn't SOLID to start with.
|
|
Re-examination of assembly reveals use of &line->frontsector->soundorg
instead of buttonlist->soundorg.
|
|
|
|
Thanks to Matt Davis (3nT) for providing a detailed report for this
gamepad.
|
|
Verified against disassembly. Otherwise, other side does not see name
changes as anything other than a message.
|
|
We already have 1280x960, which is the correct aspect ratio. This
means that when running at 1080p the windowboxing borders will be
slightly thicker, but if we're already showing borders anyway, it's
better to at least use the correct aspect ratio.
This fixes #460. Thanks to Doom_user for asking about this on
Doomworld: http://www.doomworld.com/vb/post/1316735
|
|
strdup() can theoretically fail and return NULL. This could lead to
a crash or undesirable behavior. Add M_StringDuplicate() which does
the same thing but exits with an error if a string cannot be
allocated.
This fixes #456. Thanks to Quasar for the suggestion.
|
|
The 'inventory' field in ticcmd structures can refer to inventory
values greater than the 8-bit range, so this needs to be transferred
over the network as at least a 16-bit value in order to avoid network
desyncs.
This fixes #454 (thanks Quasar).
|
|
If there's some discrepancy between clients who are to play a game
together, a warning dialog is displayed. To acknowledge this message
and proceed, make the user press enter, not escape, which is
counter-intuitive.
This fixes #453 (thanks Alexandre-Xavier).
|
|
If LOOP_START and LOOP_END are both set to zero, ignore them. This
is consistent with other source ports.
|
|
If a substitute music track is played in a non-looping configuration
(eg. the title screen music), ignore loop tags in the file to be
consistent with other source ports. This fixes a bug that was discussed
on #245.
|
|
Totally left out one of the two sprintf calls found in HU_Responder
which is responsible for setting the player's name on the consoleplayer
node (other nodes receive it through the chat system).
|
|
Propagation of allegiance from teleport beacons to rebels missing;
verfied positioning of missing assignment against disassembly.
|
|
Incorrect field being used to retrieve player names during deathmatch
for "%s killed %s" msg; changed to match disassembly.
|
|
Same fix applied to wp_torpedo selection in P_PlayerThink must also be
applied to weapon rotation code in g_game
|
|
allow -geometry to specify fullscreen or windowed modes, like PrBoom
|
|
|
|
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.
|
|
`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.
|
|
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.
|
