Chocolate Doom

[Never_Again]

Versions prior to v3.0.0 used SDL, the newer version use SDL2. There were some issues caused by that initially but they were ironed out years ago.

 

Can you try the following?

1) Download the latest daily build

2) Extract the archive to a new dir/folder, say c:\chocotest. Be sure to not leave out any DLL files or chocolate-midiproc.exe

3) Open a command-prompt window in that folder. Right-clicking on the folder in Explorer while holding the left SHIFT key is a quick way to get that done.

4) Run this:

set path=.

then Choco's setup and change music to Native MIDI. Run Choco from setup or manually - all still from the command-prompt console, not via a frontend or Explorer.

5) While Choco is running go to the taskbar, click on the speaker icon and go to the mixer. There should be two separate sliders for Choco and the midiproc exec. Does the level meter next to the latter indicate audio being played?

 

If there is still no music audible I'd be inclined to suspect VirtualMIDISynth.

Edited March 11, 2021 by Never_Again : clarification of step 4

[peach freak]

Gave that a try and there was still no music. I tried uninstalling VirtualMIDISynth and then restarting, but no music played. When I went to the volume mixer with Chocolate Doom running, I only saw a volume bar for Chocolate Doom and not midiproc. Not sure if this would've made a difference, but I right-clicked on each file in the Chocotest folder, went to Properties, and unblocked them to see if Windows was maybe preventing chocolate-midiproc.exe.

 

Anything else to try?

[The Civ]

I've actually been having problems with audio myself since 3.0.1, and every daily build since.

Doesn't cross my mind much admittedly because I've just used 3.0.0 for the longest time since I had assumed it might pass with a few daily builds and be fixed, but it hasn't how much later.

Not sure what's the cause either, and it's really bizarre since it's just not running audio in the slightest, checking the volume mixer gives me nothing, not even Chocolate Doom itself, let alone the midiproc.

It's just straight up no audio, and no configuration seems to remedy it either. The same settings work just fine on every version of Crispy, and every 3.0.0 and prior build of Chocolate, so I'm not sure what's up here.

[Never_Again]

Try this build, compiled on Win7 x64 Pro.

 

chocolate-doom-20210223-w32.zip

 

Note that this is not the latest build, as Choco currently has an issue with saving its config and savegames to the wrong dirs. This build is also packaged with a set of DLLs different from that which comes with Choco's daily autobuilds, so it's best to unzip it into a new dir/folder. If this build solves your audio problems than the problem is with the DLLs supplied with the autobuilds.

[The Civ]

Yep, works like a charm, thanks for that.

Must be something funky going on with the autobuild DLLs.

[A.o.D.]

So I made a map for the plutonia iwad, but when I try to run it in Chocolate Doom I get an error that says "R_TextureNumForName: SW1BROWNCOM not found".

 

How is this possible?  I didn't even use that texture (I checked using the find texture tool in UDB), and I only ever used the Plutonia IWAD when selecting textures for the map.  I don't get any similar errors in GZDoom.

[chungy]

I'm pretty sure all resources in a WAD are limited to 8 characters for a name... SW1BROWNCOM definitely doesn't fit that bill.

[A.o.D.]

43 minutes ago, chungy said:

I'm pretty sure all resources in a WAD are limited to 8 characters for a name... SW1BROWNCOM definitely doesn't fit that bill.

Okay.. but I didn't add that texture.  I only used vanilla resources.  Why am I having this problem?

 

I sort of figured it out.  It had to do with the way SLADE was building patch and texturex tables.  I deleted all that and now everything works fine.

Edited March 14, 2021 by A.o.D.

[Nemrtvi]

I can't manage to compile Chocolate Doom. Using the 3.0.1 source files from GitHub. After entering the following commands according to the build instruction page...

./autogen.sh --host=i686-w64-mingw32

make

... MSYS gives the following error when compiling the .exes:

windres resource.rc -o resource.o
  CCLD     chocolate-doom.exe
  CCLD     chocolate-heretic.exe
  CCLD     chocolate-hexen.exe
C:/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/10.2.0/../../../../i686-w64-mingw32/bin/ld.exe: hexen/libhexen.a(g_game.o):g_game.c:(.bss+0x970): multiple definition of `demoextend'; hexen/libhexen.a(mn_menu.o):mn_menu.c:(.bss+0x4): first defined here
collect2.exe: error: ld returned 1 exit status
make[3]: *** [Makefile:877: chocolate-hexen.exe] Error 1
make[3]: Leaving directory '/home/User/chocolate-doom-chocolate-doom-3.0.1/src'
make[2]: *** [Makefile:1085: all-recursive] Error 1
make[2]: Leaving directory '/home/User/chocolate-doom-chocolate-doom-3.0.1/src'
make[1]: *** [Makefile:583: all-recursive] Error 1
make[1]: Leaving directory '/home/User/chocolate-doom-chocolate-doom-3.0.1'
make: *** [Makefile:436: all] Error 2

Any ideas on how to fix this?

[fabian]

You'll need to apply a patch to build with GCC 10: https://github.com/chocolate-doom/chocolate-doom/commit/a8fd4b1f563d24d4296c3e8225c8404e2724d4c2#diff-f3b172335199444627fd49cd98040fed548262ac3db5ddf56395c52144b4974d

[Never_Again]

@The Civ: can you try the latest autobuild and see if there are any audio problems?

@peach freak: if the latest autobuild doesn't solve your Native MIDI silence try my own build linked above.

[rzh]

Using Chocolate Hexen 3.0.1 (Win32) I've encountered a crash that does not take place in DOSbox. The only way I was able to continue playing the game from that save was loading it up in DOSbox, teleporting to the main hub, killing as many monsters as I could, saving it in a new slot in DOSbox, and then loading that new save in Chocolate Hexen. From that new save I've thankfully been able to finish the game properly without any other issues.

It happens in the third hub of the expansion (HEXDD.wad) while teleporting from a side level (Dark Watch) back to the main hub (Nave).

Unfortunately I have no idea how Hexen saves work so I've attached here all of my saves at the time of the crash.

The one that shows the crash is named "Dark Watch 2". All you have to do to trigger it is to walk forward through the portal and the game should crash during the "Ethereal Travel" message.

I don't know much, if anything at all, about idtech 1 or programming or DOS but I've read online that faulty code related to accessing memory (?) might not do anything in DOS but it might cause a fatal error in Windows. Is this the case here? If not, is it a bug that should be fixed?

Broken Saves.7z

 

Edit: forgot to mention, this was with both of the compatibility (Vanilla Savegame and Vanilla Demo) options on, I don't know if that makes a difference.

Edited March 17, 2021 by rzh : Added more potentially relevant information

[peach freak]

17 hours ago, Never_Again said:

@The Civ: can you try the latest autobuild and see if there are any audio problems?

@peach freak: if the latest autobuild doesn't solve your Native MIDI silence try my own build linked above.

 

Tried the latest autobuild and the Native MIDI stayed silent (I imagine it uses an updated SDL2?). When I tried your link it just takes me to the homepage of filedropper, I tried a couple of different browsers just to be sure.

[Never_Again]

I get that too now. Well, here's the latest dev build (March 12 2021):

 

chocolate-doom-20210312-w32.zip (Mediafire)

 

Same sound code, same DLLs as in the build that worked for The Civ. Hope it works for you as well.

If it does please submit an issue to Choco's tracker on Github about the autobuilds.

[fabian]

The auto-builder's SDL libraries are lacking DirectX support. 

[peach freak]

On ‎3‎/‎17‎/‎2021 at 11:54 PM, Never_Again said:

I get that too now. Well, here's the latest dev build (March 12 2021):

 

chocolate-doom-20210312-w32.zip (Mediafire)

 

Same sound code, same DLLs as in the build that worked for The Civ. Hope it works for you as well.

If it does please submit an issue to Choco's tracker on Github about the autobuilds.

 

I still had the issue. I can submit something on GitHub if you want me to, but it sounds like something is weird with my PC. I tried looking up to see if anyone else was having (even outside of Doom) issues with no music playing with SDL2 on Windows 10, but nothing was jumping out. This also happens with 3.0.0/3.0.1, so I don't think it was caused by the autobuilds. I could wait for Windows 10 21H1, don't those upgrades more or less reinstall your OS?

[peach freak]

So, it turns out the issue was caused not by VirtualMIDISynth, but by Timidity++ (2.15), found here. I got music back on Native MIDI after deleting the C:\Timidity folder. Not sure what was in there that would cause SDL2 to not play MIDIs, I checked the configuration files and nothing stuck out. As you can see, there's no installer involved, just a matter of copying and pasting the folder onto your computer.

[ReX]

I am unable to load Chocolate DooM; I get an Application Error that reads: "The application was unable to start correctly (0xc000007b). Click OK to close the application."

 

I am using v3.0.1, which I was able to use with no problems just 3 months ago. I am trying to run it on Windows 10 Pro 64-bit OS.

 

I get the error message regardless of the method I use to start Chocoloate DooM - running the application directly from its folder, running it via the Setup file, or via a batch file.

 

[EDIT: Never mind. I discovered that, somehow, I had a 2017 version of libmpg123-0.dll in my Choc. DooM folder. I replaced it with the 2020 version in the Choc DooM zip file and all works as intended. Now I need to figure out why I had replaced the 2020 version with a 2017 version.]

[chungy]

Only the DLLs from the Chocolate Doom zip file itself is supported, DLLs from anywhere else is not supported. You can see the reason why right here :)

 

I'm glad you fixed your issue!

[Juza]

Please an option to fix the sound bug in MAP08?

[maxmanium]

3 hours ago, Juza said:

Please an option to fix the sound bug in MAP08?

 

What? That's totally against this source port's philosophy.

[Juza]

8 hours ago, maxmanium said:

 

What? That's totally against this source port's philosophy.

There's options to fix the savegame limitation and the demo limit. I don't see why allowing another an option to remove an annoying bug that puts most people off vanilla-made MAP08s would be too far off.

[seed]

What is this sound bug, anyway?

[maxmanium]

3 minutes ago, seed said:

What is this sound bug, anyway?

 

Oversight from upgrading the engine to support Doom 2 format. Since map 8 is the boss level in Doom they made it so the sound effects don't cut off at a certain distance, but they forgot to remove it for Doom 2.

[fabian]

https://doomwiki.org/wiki/Sound_effects_behave_differently_on_level_8

[omx32x]

5 minutes ago, fabian said:

https://doomwiki.org/wiki/Sound_effects_behave_differently_on_level_8

damn this is... so weird

i wonder how many quirks doom has that are exclusive to levels that only the hardcore minority of the fan base knows

[Maximum Matt]

There's a few, dude, there's a few

[Edward850]

7 hours ago, Juza said:

There's options to fix the savegame limitation and the demo limit. I don't see why allowing another an option to remove an annoying bug that puts most people off vanilla-made MAP08s would be too far off.

The save game limit was situational, it didn't actually change any level behaviour and for the most part was extremely unpredictable for both the end user and level designers (you can have a level appear to save fine initially only to eventually fail because too many ammo drops were left by the player). Also it was tied directly to the frame buffer size so the whole thing was a wash no matter what angle.

 

The demo limit isn't actually a change from vanilla. You could already set that to something as big as you like, as long as you had the memory to allocate to it in advance. That setting just makes the process automatic.

 

Meanwhile the map08 audio bug is a recognised phenomenon that level designers have worked with/around for decades. It's expected to be there, like it or not.

Edited April 2, 2021 by Edward850

[adamastor]

Speaking about the savegame and demo limit, I came across Chocolate Doom + only recently and, the prospect of rasing Choco's capabilities akin to the exe hacks, enabling it to be used for limit-removing WADs, sounds awesome.
Is there a way to include that as a hack or mod for the recent builds, or was that absorbed into the main version?

[maxmanium]

30 minutes ago, Adamast0r said:

Speaking about the savegame and demo limit, I came across Chocolate Doom + only recently and, the prospect of rasing Choco's capabilities akin to the exe hacks, enabling it to be used for limit-removing WADs, sounds awesome.
Is there a way to include that as a hack or mod for the recent builds, or was that absorbed into the main version?

 

I was thinking about this too. I think about distributing a hex-edited exe only to realize that it wouldn't work with Chocolate anyway.