Chocolate Doom not exiting properly

I am using Chocolate Doom version 3.0.1-win32 with Windows 11 Home OS. It runs OK in-game but when I exit the music still plays, the launcher freezes and the application cannot be closed. If you launch again the two applications overlay so you get the music from both at the same time. I have tried launching from GZDB and had the same issue so it is not the launcher causing the problem.

Does anyone know how to resolve this? It is a real pain for testing.

Try the latest build? PR probably means pre-release so it's almost there:

https://github.com/chocolate-doom/chocolate-doom/actions/workflows/main.yml

Direct links here:

32bit: https://nightly.link/chocolate-doom/chocolate-doom/actions/runs/8309676851/MSYS2%20MINGW32.zip

64bit: https://nightly.link/chocolate-doom/chocolate-doom/actions/runs/8309676851/MSYS2%20UCRT64.zip

Not sure it's going to fix the problem if there is a problem, could be a system issue/hang, but it's worth a try.

On 3/19/2024 at 5:01 PM, purist said:

I am using Chocolate Doom version 3.0.1-win32 with Windows 11 Home OS. It runs OK in-game but when I exit the music still plays, the launcher freezes and the application cannot be closed. If you launch again the two applications overlay so you get the music from both at the same time. I have tried launching from GZDB and had the same issue so it is not the launcher causing the problem.

 

Does anyone know how to resolve this? It is a real pain for testing.

I know very little about Chocolate since I don't use it, but Windows 11 is a 64-bit operating system with no 32 bit version. The fact that you are using a 32 bit build of Chocolate on an x64 system might be the cause, so just get the 64 bit build and try to reproduce the crash. If you can't reproduce it problem solved, if it happens again just create a github account and post the repro steps and every detail you can (preferably with logs attached) on the github Chocolate page:

https://github.com/chocolate-doom/chocolate-doom

27 minutes ago, DreadWanderer said:

The fact that you are using a 32 bit build of Chocolate on an x64 system might be the cause

No it isn't, Windows has full support for running x86 binaries under x86_64. Please do not provide this misinformation elsewhere.

9 minutes ago, Edward850 said:

No it isn't, Windows has full support for running x86 binaries under x86_64. Please do not provide this misinformation elsewhere.

I said it might be the cause, not that it definitely is, no need to get all aggressive. Thanks for the info.

The problem with "might" and "maybe" is people take it to mean that it is, and that's how misinformation starts. I'm never really happy with letting that spread around, creates too many problems. Least we have another "Doom is 2D" misinformation drive again.

On 3/19/2024 at 8:30 AM, CacoKnight said:

PR probably means pre-release so it's almost there:

Only as information:

"PR" in this context means "Pull Request."

A pull request is a request for someone to merge code that you've written into their repository (to "pull it into" their code base).

The actions you're seeing there are automated build checks against pull requests to ensure the new, proposed code didn't break anything. Often these checks are prerequisites for merging new code into the code base (it's a sensible precaution).

Just now loaded doom2 with choco 3.01 with win11 home and had no problems with sound or exiting

Thanks to those who have replied with suggestions. Next time I use my laptop I will continue looking for a solution or provide more information that may help someone else to do so.

Since sound is maybe an issue, you could try running it with -nosound or -nomusic and see if it exits normally that way. If it does that helps narrow down the problem.

This is most likely an issue with midiproc, which has been removed in dev versions of Chocolate Doom. I suggest running a nightly build or getting a recent Github Actions artifact. (Go here, scroll to the bottom and download either MINGW32 for 32-bit or UCRT64 for 64-bit.)

58 minutes ago, mikeday said:

(Go here, scroll to the bottom and download either MINGW32 for 32-bit or UCRT64 for 64-bit.)

First two links I posted are the newer build of that one (probably the same but with a release number), and they work without a GitHub account, less confusion IMO. Your call purist, I don't even know what you meant with that reply, did you try any of the suggestions?

I opted for the latest artifacts from the master branch. As I matter of good practice I wouldn't point people to artifacts associated with pull requests; the associated branch might be behind master and may contain unstable/unapproved code. In this particular case it's they're pretty much identical, but that definitely isn't true in general. (FYI, the branch that you grabbed from is staging for the next official release, which is mostly just working on getting the changelog up to date.)

On 3/21/2024 at 11:51 PM, CacoKnight said:

Your call purist, I don't even know what you meant with that reply, did you try any of the suggestions?

I haven't tried anything yet, but I'm grateful for as many suggestions as possible since there doesn't seem to be a silver bullet fix.

I don't get much time to use my laptop but I will report back when I do.

Sorry for the double post, but just to update, I downloaded MSYS2 UCRT64 and no longer experience the error using that version so thank you @mikeday for the successful solution.

Beforehand I tried running without sound as plums suggested and without pwads but that didn't help. There was no stdout in the version of Chocolate Doom I was using so I don't know if I can be any further help in diagnosing what went wrong.

On 3/20/2024 at 4:40 PM, Edward850 said:

Least we have another "Doom is 2D" misinformation drive again.

We all know that Doom is actually 1.5D...