when we get eof, stop the loop immidiately and do not
rely on the read to eventually return an error.
when convM2S() fails to decode the message, error out
and stop the loop. there is no point in continuing.
the pause function is different from just accessing the menu: it pauses both
single and multiplayer games, stops music and sound, and is recorded in demos
(does not cause a desync, unlike menu access).
this uses Kprint rather than Kbreak because Kbreak is e.g. Kctl+pause on some
keyboards.
blazing doors are a "fast" door type with its own sound effects, introduced in
doom2. doom2 map 2 has one right at the beginning.
this fixes two bugs:
- when a closing blazing door is completely shut, the closing sound effect is
erroneously played again (the first time being when it began closing). this
gives the impression of two doors closing.
- when reopening a closing blazing door (standing underneath a blazing door
while it's closing), the sound effect for regular doors opening is played,
instead of the one for blazing doors, because of a missing case in the switch
statement.
make kbdproc() and mouseproc() share fd table with the main proc
and not explicitely close the file descriptors. so /dev/mouse gets
closed *after* /dev/draw/new to avoid the white window refresh issue.
mthing->angle is a signed short, and if ANG45 * mthing->angle/45 < 0, the
result of the right shift is sign extended.
afaik, an being 16bit in the dos version of doom, you'd endup with a
negative array offset, which would just access values from adjacent arrays
(finetangent[] for finecosine[], and finecosine[] for finesine[]), and it
would result in a misplaced teleport fog in some circumstances (fog is not
in front of the player on respawn, hence "silent teleport"). so, this fix is
bug incompatible, but this only affects live multiplay.
to test:
% hget http://doomedsda.us/dm/ahfx7_2.zip | unzip -sv
extracting AHFX7_2.TXT
extracting AHFX7_2.LMP
% mv AHFX7_2.LMP ahfx7_2.lmp
% games/doom -playdemo ahfx7_2
[...]
doom 10553: suicide: sys: trap: fault read addr=0x400429e10 pc=0x205b45
KEY_F11 and KEY_F12 are not KEY_F1+11 and KEY_F1+12 as it is assumed in
runetokey(), which prevents these keystrokes from being used. rather than
change runetokey(), it seems better to just change the key definitions in
doomdef.h (the new values don't correspond to any other keys anyway).
F11 is the gamma correction key. to make gamma correction actually work,
i_video.c:I_SetPalette must also take into account usegamma (this was just
never ported). cf i_video.c:UploadNewPalette in source code release.
F12 is the spycam key. the spycam switches the renderview to a different player
during a coop game, or when watching a multiplayer demo. this feature only
changes the renderview; sounds, palette effects, status bar, etc. are still
from the first player's perspective.
a typo in st_stuff.c:ST_Responder prevents idclev (change level) cheat to work
in doom2 and final doom (gamemode == commercial): episode is set to 0, when
that's invalid, and ST_Responder just returns.
to test, while ingame type idclev, followed by:
. doom1: episode (1-3 or 1-4) then map number (1-9)
. doom2/final doom: map number (1-32)
incidentally, if the last digit typed is 1, the player's weapon will switch to
the fist, because of a different bug (basically kbdproc registering two events
when pressing a key, for 'c' and 'k' case).
this bug was introduced in the plan9 port, and since i_sound.c compiles with
no warning, it was never noticed. in effect, the statement between the
unterminated comment and the next is ignored. channelids[] is used in addsfx()
to avoid re-adding certain sounds if they are already playing. one of those is
sfx_sawful, and because of this bug, it is added again each tic during which
the player fires the chainsaw, rather than reset every tic.
compare firing the chainsaw continuously with and without the patch (without
hitting an enemy).
basedefault[], the default path to the config file, is never set and remains
blank, unless -config %s is used (cd d_main.c). when games/doom attempts to
open the file, it silently fails and no config file is ever read or written.
this patch sets basedefault to a file in whatever directory a valid wad is
found in I_IdentifyWAD().
due to a typo in p_inter.c:P_TouchSpecialThing(), a message that is supposed
to show up when the player picks up a medikit while low on health (< 25), is
never displayed. the check for low health is done after the health is already
increased, so the condition is never true.
a cosmetic bug in all old doom executables that also seems interesting to fix.
to test: compare message displayed when picking up a medikit with and without
the patch
due to a typo in st_stuff.c:ST_updateFaceWidget(), doomguy mistakenly never
looks shocked when taking more than 20 damage, but rather when he gains more
than 20 health while being hit.
this is a cosmetic bug in all old versions of doom's executables, but it seems
appropriate to fix.
simple test: fire a rocket at a nearby wall, taking enough damage.
these emulate bugs present in select versions of the released doom executables.
they are required to correctly play demos recorded with these but affect the
gameplay, so should be otherwise disabled.
-nobounce: lost souls don't bounce off floors and ceilings like intended due
to a misplaced check; this is fixed from ultimate doom on, but doom and doom2
are still affected.
-noztele: in final doom 1.9, things' altitude was erroneously not set to the
floor's height after teleporting. this was fixed in later versions of the
executables.
examples of desyncing demos:
(plutonia.wad, without -noztele) http://doomedsda.us/lmps/946/2/30pl2646.zip
(doom2.wad, without -nobounce) http://doomedsda.us/lmps/945/3/30nm2939.zip
gamemode is set according to the name of the main wad (cf. d_main.c), i.e.:
- doom1.wad: (shareware doom1, ep1 only) gamemode == shareware
- doom.wad: (registered doom1, ep1-3) gamemode == registered
- doomu.wad: (ultimate doom, ep1-4) gamemode == retail
- doom2.wad, plutonia.wad, tnt.wad: gamemode == commercial
most doom.wad's distributed online are, in fact, ultimate doom.
if your ultimate doom wad is correctly named doomu.wad, some switches in
episodes 2-4 won't swap their texture when toggled, because
p_switch.c:P_InitSwitchList() is only checking for registered doom1.
easy way to test: demo2 in either registered or ultimate doom: the player flips
a switch right at the beginning of the demo; if the main wad is called
doomu.wad, the switch won't change its texture.
% games/doom -playdemo demo2
if you rename the wad to doom.wad or alter d_main.c:IdentifyVersion, the switch
will swap its texture like it should.
this function is used when playing demos from external lumps. the game just
exits without this patch.
to test this, download a demo lump from somewhere, and play it with -playdemo %s
where %s is the file's name, without the .lmp extension:
(note that this one is a doom 2 demo, so it requires doom2.wad)
% hget http://doomedsda.us/lmps/945/3/30nm2939.zip | unzip -sv
extracting 30nm2939.LMP
extracting 30nm2939.txt
% mv 30nm2939.LMP 30nm2939.lmp # checking for a lump filename is case sensitive
% games/doom -playdemo 30nm2939
the game exits when the demo ends. also, note that this demo will desync on
map06 (the crusher), because of an unrelated bug (that's another patch :>)
note: filelength() returns vlong, but file lengths for doom lumps are ints.
however, this might be used elsewhere (networking), so i'd leave it this way.
the code used P_Random()-P_Random() in some places which has
undefined evaluation order resulting in the wrong pseudo random
numbers being returned causing demo playback to desync.
this change adds P_Random2() function which returns the right
delta-random number and uses it in place of P_Random()-P_Random()
expression.
