The following bug was originally reported on Sourceforge by fraggle, 2007-12-11 13:00:10:

STRAIN demo str22-uv.lmp desyncs.

Demo can be found here:

http://www.doomworld.com/idgames/?id=8506

The following bug was originally reported on Sourceforge by *anonymous, 2008-07-06 16:22:53:

Whenever you pick up an item, there is a short freeze. Only happens in fullscreen mode.

The following bug was originally reported on Sourceforge by *anonymous, 2007-06-21 18:46:07:

Demo attached.

The following bug was originally reported on Sourceforge by *anonymous, 2007-06-19 14:09:36:

I tried to play Eternal Doom with the current svn version (rev 917) and FreeDoom. After choosing a skill level, Choc Doom crashes returning the following error message:
Error: R_ProjectSprite: invalid sprite frame 85 : 0

rabyte <rabyte__gmail>

The following bug was originally reported on Sourceforge by *anonymous, 2007-07-21 16:43:06:

While a door is getting opened or closed, you will not hear the opening/closing sound when you open/close it again.

The following bug was originally reported on Sourceforge by lemonzest, 2008-01-11 14:26:31:

was looking trough p_map.c of prboom for other maps that they fixed that used to desync and found some links for maps, so i decided to test them in chocolate doom and they desynced with both the default and alternate -spechit numbers. maybe chocolate doom needs to resync with prboom for its compatabilty fixes? (spechit/playeringame etc) i'll test later if the other demos listed in p_map.c desync

i wrote this in IRC.

<Lemonzest> http://www.doomworld.com/tas/hf181430.zip
<Lemonzest> that one
<Lemonzest> with hr.wad
<Lemonzest> http://www.doomworld.com/tas/hr181329.zip desyncs too
<Lemonzest> found them in prboom+ p_map.c because they had fixes, so decided to test in chocolate
<Lemonzest> maybe you need to resync with prboom+?
<Lemonzest> must be a but, also desyncs with the alt number (2230937832)
<Lemonzest> ^bug

The following bug was originally reported on Sourceforge by ajapted, 2005-11-21 11:04:10:

Chocolate Doom crashes when I try to save the game
in the level I'm working on. This level is not extreme
(around 1050 things and 1800 linedefs). I'm assuming
the savegame buffer is simply overflowing. The same
crash happens with the original DOOM2.EXE as well.

The following bug was originally reported on Sourceforge by ajapted, 2005-11-21 11:08:21:

Small one: the I_EndDoom should check for SDL_Quit event,
otherwise the user tries to close the window by clicking
on the close button and nothing happens, and that's
just rude :).

The following bug was originally reported on Sourceforge by fraggle, 2007-12-14 18:48:28:

The way graphics modes are selected and configured is hugely overcomplicated and needs to be revamped. It also causes problems for users with widescreen monitors as there is no way to select a specific graphics mode. Setup should not list graphics modes which are not present.

Mode selection should be based around simply selecting a screen mode, with screen_width / screen_height values in the configuration file. Chocolate Doom should then choose an appropriate scale factor to fit the screen.

If the screen mode is bigger than the scaled image, the image should appear centered in the screen. "Letter box mode" is a special case of this.

There should be a check box to enable / disable aspect ratio correction. Aspect ratio correction should be turned on by default.

The low-res modes should be special cased. 320x200 and 640x400 are often real modes that do what we want. Aspect ratio corrected 320x240 mode should NEVER appear in the video mode selection dialog, as it looks awful.

First time running, a sensible selection should be made for a default mode - probably 640x480 as default. If the monitor is widescreen, a widescreen mode should be selected (as this will likely give square pixels). The aspect ratio of the largest screen mode can be used to determine if the monitor is widescreen.

It may be worth adding horizontal screen squashing aspect ratio correction in addition to the current vertical screen stretching correction, as this will allow fitting to more common screen modes (800x600).

The following bug was originally reported on Sourceforge by fraggle, 2006-12-16 21:55:45:

I've heard multiple reports of problems of sound being played at the wrong sample rate. Perhaps cards that only support 48khz output and Chocolate Doom continue regardless?

The following bug was originally reported on Sourceforge by phf, 2008-11-17 06:14:44:

Trying to build revision 1380 on OS X 10.4 fails because sched.h does not have a cpu_set_t defined. Here are some details.

Repository Root: https://chocolate-doom.svn.sourceforge.net/svnroot/chocolate-doom
Repository UUID: ee5ca603-980d-0410-972c-a23fc50d79fe
Revision: 1380

i_main.c: In function 'SDL_main':
i_main.c:66: error: 'cpu_set_t' undeclared (first use in this function)
i_main.c:66: error: (Each undeclared identifier is reported only once
i_main.c:66: error: for each function it appears in.)
i_main.c:66: error: parse error before 'set'
i_main.c:68: warning: implicit declaration of function 'CPU_ZERO'
i_main.c:68: error: 'set' undeclared (first use in this function)
i_main.c:69: warning: implicit declaration of function 'CPU_SET'
i_main.c:71: warning: implicit declaration of function 'sched_setaffinity'
make[2]: *** [i_main.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

The following bug was originally reported on Sourceforge by raztk, 2006-11-20 11:22:29:

The crash happens when I go to the room where the cyberdemon and all the barons are. I shoot with the BFG and after a few seconds I get the crash.

This is what I get from GDB:

Program received signal SIGSEGV, Segmentation fault.
0x0042e2a7 in P_RunThinkers () at ../src/p_tick.c:121
121 currentthinker = currentthinker->next;

I'm using my own build, r756.

The following bug was originally reported on Sourceforge by grazza, 2006-03-01 11:19:51:

When the ammo type for a weapon is set to type 5
(unlimited ammo) via dehacked, whenever this weapon is
fired, the maximum of shells that can be carried is
reduced (it can go below zero too).

This bug is also present in Boom, (Win)MBF and Prboom(-
plus). It is fixed in Eternity. Quasar does not (as
far I can tell) specifically mention this fix in the
changelog, but does refer to a rewrite of
deh_procWeapon, which sounds like it might have
something to do with this.

The following bug was originally reported on Sourceforge by *anonymous, 2007-02-13 22:45:11:

The death sound in marina.wad does not play (it is unusually long)

The following bug was originally reported on Sourceforge by fraggle, 2008-07-16 20:06:49:

When using the new mmap()ed WAD I/O, some graphics can be rendered differently to when using the original non-mmapped code.

Attached is a demo of DM6.wad which displays differently when using the -nommap parameter.

The following bug was originally reported on Sourceforge by raztk, 2006-12-16 16:00:29:

The crash happens if you use the '-warp' command-line parameter with DOOM.WAD with only one argument (i.e. '-warp 1').

I tested it with DOOM.EXE and it doesn't crash.

Additional information:

Program received signal SIGSEGV, Segmentation fault.
At C:/chocolate-doom/codeblocks/../src/d_main.c:1625

Callstack attached.

The following bug was originally reported on Sourceforge by *anonymous, 2007-10-24 23:39:44:

Linedefs appear to only work from one side in build 979. A good example of this is the portal at the end of the first level in Hell Revealed.

The following bug was originally reported on Sourceforge by *anonymous, 2007-12-17 05:23:18:

When processing the compilation script on Mac OS 10.5, SDL fails to compile, producing these error messages:

/bin/sh ./libtool --mode=compile gcc -I/Users/Josef/chocolate-doom/install/include/SDL -I./include -D_GNU_SOURCE=1 -DTARGET_API_MAC_CARBON -DTARGET_API_MAC_OSX -fvisibility=hidden -D_THREAD_SAFE -force_cpusubtype_ALL -fpascal-strings -c ./src/audio/macosx/SDL_coreaudio.c -o build/SDL_coreaudio.lo
gcc -I/Users/Josef/chocolate-doom/install/include/SDL -I./include -D_GNU_SOURCE=1 -DTARGET_API_MAC_CARBON -DTARGET_API_MAC_OSX -fvisibility=hidden -D_THREAD_SAFE -force_cpusubtype_ALL -fpascal-strings -c ./src/audio/macosx/SDL_coreaudio.c -fno-common -DPIC -o build/.libs/SDL_coreaudio.o
./src/audio/macosx/SDL_coreaudio.c: In function 'Core_CloseAudio':
./src/audio/macosx/SDL_coreaudio.c:159: error: storage size of 'callback' isn't known
./src/audio/macosx/SDL_coreaudio.c:172: error: 'kAudioUnitProperty_SetInputCallback' undeclared (first use in this function)
./src/audio/macosx/SDL_coreaudio.c:172: error: (Each undeclared identifier is reported only once
./src/audio/macosx/SDL_coreaudio.c:172: error: for each function it appears in.)
./src/audio/macosx/SDL_coreaudio.c: In function 'Core_OpenAudio':
./src/audio/macosx/SDL_coreaudio.c:203: error: storage size of 'callback' isn't known
./src/audio/macosx/SDL_coreaudio.c:224: error: 'kAudioUnitComponentType' undeclared (first use in this function)
./src/audio/macosx/SDL_coreaudio.c:225: error: 'kAudioUnitSubType_Output' undeclared (first use in this function)
./src/audio/macosx/SDL_coreaudio.c:226: error: 'kAudioUnitID_DefaultOutput' undeclared (first use in this function)
./src/audio/macosx/SDL_coreaudio.c:256: error: 'kAudioUnitProperty_SetInputCallback' undeclared (first use in this function)
make: *** [build/SDL_coreaudio.lo] Error 1

Following the instructions located at http://www.nabble.com/SDL-not-building-on-OS-X-10.5--28Leopard-29---to13426719.html does not affect the compile (although those patches appear to be for 1.2.12 rather than the 1.2.11 the script is trying to compile).

The following bug was originally reported on Sourceforge by gammafactorial, 2008-09-29 22:26:47:

chocolate-doom -file shdwpit.wad -warp 01 exits with a segmentation fault instead of the visplane overflow message like the exe

The following bug was originally reported on Sourceforge by raztk, 2007-07-21 16:54:10:

I encountered it for the first time in E1M6. When you "use" a switch, it doesn't toggle and don't do any sound. A demo is included.

The following bug was originally reported on Sourceforge by *anonymous, 2008-08-19 13:46:27:

The following weapons mod "Insane weapons" ( http://www.doomworld.com/idgames/index.php?id=4442 ) seems to work perfectly fine in vanilla, yet is unstable when playing in Chocolate doom. Sometimes crashes when firing, or lowering off the ledge at the start in map29.

The following bug was originally reported on Sourceforge by grazza, 2006-01-03 03:32:52:

If Max Health (default value 200) is set in a dehacked
patch, then stimpacks and medikits can increase the
player's health up to this value. In Doom2.exe they
cannot take it above 100%. Consider this simple
dehacked patch:

Patch File for DeHackEd v3.0

Note: Use the pound sign ('#') to start comment

lines.

Doom version = 19
Patch format = 6

Misc 0
Max Health = 200

This should change nothing, as it simply sets Max
Health to its default value. However, if you load this
patch in Chocolate-Doom and warp to Doom2 map15, you
can pick up the four medikits at the start and
increase your health to 200%.

I have tested this by applying the patch to Doom2.exe,
and the behaviour there is as expected: stimpacks and
medikits don't increase your health above 100%.

This bug also appears in Boom and its descendents. I
noticed it when testing wotdoom3
(http://www.doomworld.com/idgames/index.php?id=14032\).

The following bug was originally reported on Sourceforge by fraggle, 2007-09-11 08:37:23:

Bug report from Matthew Dickinson.

Windows XP SP2, Pentium 4, IWAD confirmed at v1.9. Revision ~ 969.

> > I don't mean to make your day any worse, but it's also crashed at a
> > few other places, I just didn't note where. Since I save frequently
> > it's not a big deal to me. The Icon of Sin one is the only one that's
> > interfered.
>
> Ok. Do you have a specific sequence of actions that I can take in
> order to make it crash on Icon of Sin? Or do you just start it up and
> wait until it crashes?

All I do is try to beat it. I think to beat it you go up to the switch
at the top of the platforms and you switch it on, then that raises the
rectangular prism in the lava and you wait for it to stop rising, and
by that point I don't think it's ever crashed. But then as I head
towards the spire-thing, usually about as I'm falling towards it into
the lava, running, about to get to it to lower it so I can get on, it
freezes. Like I'm on the lower platform part and I'm running toward it
and it closes. Not freezes, just closes. No error message or anything,
I'm just back in Windows like I'd never loaded the game.

umm, now it just crashed twice. I'm positive I'm using the latest
build that you just linked as well as the wad from idsoftware.com.
Like I'm heading toward the spire and the icon has shot out the
spinning, golden skull cube (which spawns the monsters) and the last
time it crashed it did it just as I was passing by, in front of, the
trajectory of that skull cube. I'm always facing the icon when it
crashes, I think, and I can be coming at it from any direction. I bet
it has something to do with the size of the room and the number of
enemies and shit on screen. I'm playing on Hurt Me Plenty, so it's not
that many enemies. It's probably something to do with my setup. I'm
not sure what to tell you. I recently re-installed XP Home SP2 about a
month ago on a formatted drive. I don't usually got many programs
running in the background, although today it's been Firefox and
Photoshop Elements and sometimes Winamp. Also I've played through a
lot of Doom 1 and I don't remember it having any problems in Chocolate
Doom. I got a GeForce 8600 GT by XFX. Let me know if you need any
other information.

Yep, I just got it to crash twice more by running past the spinning
skull cube thing (that the icon spits out)... that's what it is. It
doesn't like that thing.

The following bug was originally reported on Sourceforge by gammafactorial, 2008-08-07 08:47:26:

The pillarbox on non-4:3 fullscreen displays flashes when taking damage or picking up items. This is annoying.

The following bug was originally reported on Sourceforge by *anonymous, 2008-04-10 09:52:42:

The joystick configuration dialog does not initialise the SDL joystick subsystem correctly and needs fixing.

The following bug was originally reported on Sourceforge by *anonymous, 2008-12-09 22:46:35:

When reaching the intermission (exit) in levels occupying MAP33, Chocolate Doom closes. When Doom v1.9 reaches the intermission after level 33, it does not draw nor require a level name graphic. This means that Chocolate Doom will terminate itself in a Doom-compatible WAD where Doom would continue.

You could, for instance, play through a level marked as 33 in Doom, or even record a demo and play it back (as long as you quit at the intermission)... but in Chocolate Doom the demo recorded in Doom would end before the intermission screen, if one were to try to play it back.

Note that Doom does terminate after levels 34-35, with a
"Bad V_DrawPatch" error when reaching the intermission screen (placing level name graphics does not change this, because it seems to require an invalid or null lump name), so only level 33 needs some sort of fix in Chocolate Doom.

The following bug was originally reported on Sourceforge by raztk, 2007-07-22 18:17:43:

Right now, Chocolate Doom does not emulate the "all-ghosts" bug, but PrBoom (PrBoom+ is the one I used) does. The demo I was trying to play back is manorbug.lmp (attached). You need to use it with manor.wad from "The Master Levels for Doom II".

The following bug was originally reported on Sourceforge by fraggle, 2008-04-10 09:50:24:

The pcsound_bsd driver needs updating to support FreeBSD. The driver/interface seems to be exactly the same, but the header file is different (dev/speaker/speaker.h instead of dev/isa/spkrio.h).

The following bug was originally reported on Sourceforge by ajapted, 2006-06-25 09:32:00:

Back when DOOM came out, people were blissfully happy
because filenames never contained spaces.

Now spaces in file paths are everywhere, but the poor
old response file parser from Doom cannot cope with the
typical "C:\Programs and Files\Foo Bar Baz".

Hence the response file parser needs to handle quotes
in @ response files. Launcher programs especially need
this. The following code from EDGE (look for
ParseOneFilename) may be useful to fix it:

http://edge.cvs.sourceforge.net/edge/edge/m\_argv.cpp?revision=1.11&view=markup

The following bug was originally reported on Sourceforge by fraggle, 2006-12-16 22:06:14:

As reported by Myk. Cannot reproduce in Linux; perhaps a Windows-related issue?

The following bug was originally reported on Sourceforge by *anonymous, 2007-12-20 11:45:40:

filejunkie@gmail.com
filejunkie@filejunkie.spb.ru
Trying to start chdoom with "-playdemo xxxx" where xxxx is invalid filename causes crash.

The following bug was originally reported on Sourceforge by *anonymous, 2008-07-08 16:47:11:

when doom2 tries to play the original demos. chocolate doom exits and a message appears saying "demo is from a different game version. (read 106 should be 109)"

The following bug was originally reported on Sourceforge by fraggle, 2007-09-11 09:08:31:

When using chocolate-setup on Windows, a console window sometimes briefly appears.

This occurs when Chocolate Doom is invoked to determine which IWADs are available. The system() function is used to invoke it, which is probably causing a command window to appear. This should be switched to exec() or whatever the Windows equivalent is.

The following bug was originally reported on Sourceforge by *anonymous, 2007-12-11 09:32:25:

08:13 < CSonicGo> BUG found: if testing mouse settings in windows version of
chocodoom setup, setup hangs and map01/e1m1 music plays

09:30 < CSonicGo> hello fraggle 1.0 works fine now I just can't test my mouse
settings in setup :(
09:30 < fraggle> doh
09:30 < fraggle> on windows? or linux
09:30 < CSonicGo> windows
09:30 < CSonicGo> setup hangs
09:30 < fraggle> bummer
09:31 < CSonicGo> when I end the task, chocodoom starts in the test mode. :s

The following bug was originally reported on Sourceforge by fraggle, 2006-12-16 23:36:07:

Under MacOS X, Chocolate Doom crashes if music is enabled - if ran with -nomusic, no crash occurs.

This seems to be a bug in SDL_mixer's native midi code for MacOS. If Mix_PlayMusic is run with looping turned on, the program crashes when the music loops. Playing with looping disabled (so that it plays once and then stops), no crash occurs.

The following bug was originally reported on Sourceforge by fraggle, 2007-07-22 14:43:27:

When items are picked up (eg. health potions), there is a pop sound at the end of the item pickup sound effect.

Noted on Windows. Occurs on multiple machines. Changing the sampling rate does not fix the bug but does make it quieter.

The following bug was originally reported on Sourceforge by fraggle, 2005-09-08 21:49:09:

Sound issues when playing on a Creative Audigy 2 under
Windows XP SP2:

* Music does not play

• Some sounds do not play
• Sounds are sometimes cut off

PrBoom 2.3.1 works fine when using the same .dlls.

The following bug was originally reported on Sourceforge by fraggle, 2008-02-09 19:56:32:

The fullscreen video modes list in the setup tool is generated using SDL_ListModes. On Windows, the modes list is different for DirectX and Windows GDI, so some of the modes that may be valid for the configured settings may not be displayed.

http://www.doomworld.com/vb/post/706686

The following bug was originally reported on Sourceforge by *anonymous, 2008-08-20 08:45:06:

The Windows resource files assume that you're always compiling on Windows itself, however when using MinGW on Linux, you need to modify the resource files to use a forward-slash directory separator instead of the backslash.

The following bug was originally reported on Sourceforge by fraggle, 2006-12-20 03:41:25:

Email from sofaking:

"

I think I've found another bug. It's a small one, though.

When you press F9 without previously selecting a quicksave slot, chocolate doom displays an extra character at the end of the "no quicksave slot selected!" message.

The character is constantly changing, and appears to be looping through all 256 ascii characters.

I started up vanilla doom (the shareware one), and the bug didn't appear there. I'm pretty sure this doesn't appear in the other vanilla EXEs, but like my last bug report, please correct me if I'm wrong.

"

The following bug was originally reported on Sourceforge by fraggle, 2007-09-14 13:37:50:

The savegame code in Chocolate Doom has been changed to read/write directly to files rather than a memory buffer. This removes the savegame buffer size limit. To stay the same as Vanilla Doom, the file size is checked at the end of writing a savegame, and bombs out if the Vanilla limit was exceeded.

However, this means that unlike Vanilla Doom, even if the game bombs out due to the savegame limit being exceeded, the savegame will still be written to disk.

Ideally, savegames should be written to a temporary file, and the temporary file renamed to the actual file once the game has finished saving. Thus, if the limit is exceeded, the game will behave like Vanilla Doom.

The following bug was originally reported on Sourceforge by *anonymous, 2008-08-12 15:12:36:

Demo game runs with sound but if a game is started then the first sound effect - shooting, monster shout, picking up item - chashes the game.

Chocolate Doom 1.1.1 is running on Linux 2.6.26.2
with Ubuntu 8.04

There is no error reported by the game it just freezes.

The following bug was originally reported on Sourceforge by filejunkie, 2007-12-20 22:28:27:

Starting chdoom like this:
chocolate-doom.exe -iwad doom1.wad
Causes chdoom to crash when trying to play demo or start game.
Stderr.txt contains "Error: Demo is from a different game version! (read 3, should be 109)" or "Error: W_GetNumForName: STTMINUS not found!", respectively.
I guess it will cause core dump on Unix-like systems and I guess it can't be good behavior.

The following bug was originally reported on Sourceforge by mikeshere, 2008-08-19 12:05:57:

The application icon normally displayed in the titlebar of the game in windowed mode is not displayed, instead a stock Microsoft icon is used instead. This only happens when using the newer bitmap-graphics user interface, such as the original Luna theme on all WinXP installs or the Royale theme on Media Center installs; the game properly has an application icon in the title bar when using the Windows classic mode (Windows 98-style).

Attached picture demonstrates the lack of a Chocolate Doom-specific icon in the title bar.

The following bug was originally reported on Sourceforge by lemonzest, 2008-01-16 00:06:50:

Hi

been trying to setup a few net games and uses who had latest svn build from someone else had version 1.0.0 in the window title, i build my own versions using codeblocks which does not use configure.in for version numbers and uses config.h which was not updated 1.0.0 was released so the builds differ and cant connect till i updated my build to reflect the changes.

The following bug was originally reported on Sourceforge by fraggle, 2007-06-20 11:32:30:

Reports that on some systems it crashes with "Error: R_MapPlane: 316, 316 at 244". On others it just desyncs.

The following bug was originally reported on Sourceforge by raztk, 2007-07-22 11:05:10:

The new mouse options added in r918 are not being saved by chocolate-setup. Although they are being saved by chocolate-doom, they will get removed again the next time you run chocolate-setup.

The following bug was originally reported on Sourceforge by fraggle, 2006-12-16 22:35:43:

ep1-0500.lmp desyncs, but only on 64-bit Linux. The yellow door doesn't open; this is possibly related to the fact that the door has the same tag as an elevator elsewhere in the level.

The following bug was originally reported on Sourceforge by grazza, 2006-10-26 22:47:21:

Please see the attached file, which includes some
demos illustrating an instance in which Chocolate-Doom
fails to emulate the behaviour of
Doom2.exe+dehacked.exe.

The specific issue is that in Batman Doom, if you
switch to weapon 1, you cannot then change back to any
other weapon (probably a bug, but it's how it
behaves). Chocolate-Doom, on the other hand, will
allow you to change weapon again.

The following bug was originally reported on Sourceforge by lemonzest, 2008-01-10 00:13:59:

Hi

desync on level exit map07 of strain.wad+strain.deh which does not happen in either doom2.exe or prboom-plus

demo is ST07-237.LMP from http://competn.doom2.net/pub/sda/p-s/stmax-av.zip

demo plays back fine when using -spechit 0x01D6CF98 (same value as PrBoom-plus???)