| Age | Commit message (Collapse) | Author |
|---|
|
The floor->type and floor->crush fields of the floor thinkers added in
EV_BuildStairs() were originally left uninitialized and thus contained
random memory content.
Initialize them to make sure the floor->type field does not trigger
propagation of random content into the special and texture fields of
the adjacent sector in T_MoveFloor(). That is, make sure its value
is neither donutRaise, i.e. 11, nor lowerAndChange, i.e. 6.
Also, the chances of 32 bit of random memory being "true", i.e. 0, are
negligible.
This is functionally equivalent to what PrBoom+ is doing.
Fixes desync of mm09-512.lmp.
Fixes #368.
|
|
|
|
The source and destination arguments to memcpy() cannot be overlapping
as this is undefined behavior. In these situations memmove() must be
used instead, and OpenBSD actually throws an error if this is done.
Thanks to ryan-sg for reporting this. This fixes #510.
|
|
The Strife binary has another priority check in the first loop inside
S_GetChannel. TODO: Does DOS Doom have this as well? Find out.
Resolves issue #506.
|
|
Signed/unsigned comparison mismatches
|
|
The config file API previously relied on binding config variables
using M_BindVariable() which took a void pointer. It occurred to me
that if used on a boolean variable, this would be erroneous, but the
void pointer would make it impossible to tell. Split this into
separate M_Bind{Foo}Variable() functions based on type, which allows
for proper type checking on the pointers that are passed.
Vaguely related to #509.
|
|
Various bits of code assume that booleans are represented as 32-bit
ints and that they can be assigned to from 32-bit values. This isn't
true on all systems; fix code that does this to convert to boolean
values properly.
This is more progress towards fixing #509.
|
|
The st_stuff.c status bar code passes pointer to an entry in
weaponowned[] as an int pointer, but weaponowned[] is an array
of booleans and booleans are not always represented as 32-bit ints.
Remove the (int *) cast and ensure correct behavior.
This fixes the immediate issue in #509 (thanks floppes).
|
|
Actually, it is impossible to reach the end of these two functions
without return()ing earlier from one of the switch() statements'
branches. But since the compiler cannot know this and warns about it,
and since this warning can be escalated into an error in later
compiler versions, silence it by return()ing a dummy value at the end
of each function.
Fixes #508
|
|
Ensure that the loops to find the next weapon always terminate -
even if there are somehow no weapons equipped. Also, only ever do
weapon cycling when in the GS_LEVEL gamestate. This fixes #503 -
thanks to Fabian and raithe on Doomworld.
|
|
fixes #497
|
|
No. 2: even more endianness fixes by myself (Ronald Lasmanowicz)
|
|
No. 1: even more endianness fixes by myself (Ronald Lasmanowicz)
|
|
|
|
I figured this out while porting Chocolate to the Nintendo Wii and also had to change these lines of code.
|
|
I figured this out while porting Chocolate to the Nintendo Wii and also had to change these lines of code.
|
|
This was added a long time ago, supposedly as a workaround for
SDL_mixer issues. It's not clear that this ever properly solved the
problem, and it seems unlikely that it's doing any good any more.
Quasar has pointed out that it actually impedes performance, and
some forks may want to use SMP (Strife: Veteran Edition had to
remove it).
This fixes #484 (thanks Quasar).
|
|
|
|
as pointed out necessary by Ronald Lasmanowicz for his Wii ports
|
|
when walking inside liquids like water -- on big-endian systems
Originally reported by Ronald Lasmanowicz and fixed in his
wii-hexen port: https://code.google.com/p/wii-hexen/source/detail?r=17
|
|
Double-checked with strife1.exe
|
|
The MVIS flag, if set on an object *without* MF_SHADOW, imparts total
invisibility. This is the intended effect on players using double Shadow
Armors.
|
|
This caused Rowan to fail to take Beldin's ring from you, if and only if
you had full bullet ammo. Transcription error from the disassembly.
|
|
|
|
Scripts can have a maximum of three arguments when started
(see ACS_Execute / #80 linedef special type). This means that the
array of arguments passed must be at least three elements in
length. When loading scripts, check the argument count never
exceeds 3, and print a warning message if it does.
Don't pass pointers to structure members implicitly treating them
as elements of an array (as this relies on compiler-dependent
behavior as to how structure members are laid out). Instead, copy
values into a temporary array to make the intended behavior explicit.
This fixes #477. Thanks to Quasar for reporting it.
|
|
The minotaur uses the first four bytes of the mobj_t args[] array to
store its spawn time; after a certain amount of time has passed the
minotaur self-destructs. But the level time was being copied from the
leveltime variable without any endian conversion taking place. For
compatibility with Vanilla Hexen savegames we need to store the start
time in little endian format.
This fixes the first issue noted in #477 (thanks Quasar).
|
|
The size parameter for the destination buffer used for this string
copy was one character too short, the result being that patch lump
names using the maximum length (8 characters) were having the last
character cropped off. This in turn caused problems with custom
WADs that added new textures with names like these: the game would
exit on startup with a message like:
R_InitTextures: Missing patch in texture SKY3GOLD
Amazingly this bug was not noticed because most of the patches in
the Hexen IWAD file have short names of 7 characters or less. The
only exception I noticed was SKYWALL2 which maps to SKYWALL,
another patch, hiding the bug.
Thanks to ETTiNGRiNDER for reporting this bug to me and for
providing me with a private copy of his in-development PWAD that I
could use to find the problem.
|
|
getenv() can return NULL if the environment variable is not set, but
the result of getenv() was always being passed to M_StringDuplicate()
without any check. This could cause crashes on some platforms.
Instead, rework the code into a first stage that gets the player's
name and a second that duplicates it into a mutable form.
This fixes #455.
|
|
Eliminate tab characters and trailing whitespace. Add extra
whitespace around operators in for() expressions.
|
|
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.
|
|
|
