Release 3.1.0 master PR

[mfrancis95]

Starting this to serve as a master PR for release 3.1.0. Locking in 7f25bf6 as the commit 3.1 is based on. I figured we can use this PR for a bit to collect some more changelog additions before going live.

There are simply way too many changes to try to sift through though, so eventually we should reach some level of comfort with what we have and consider augmenting the changelog post-release if we find additional key changes that we want captured.

[turol]

Things to mention:

• improved portability by allowing disable SDL extra libs
• various windows midi improvements @ceski-1 @rfomin can you elaborate all the things that were fixed?
• -display command line parameter
• Fix mouse event causing unwanted key press d66009a
• pcsound fixes 080ed4e
• cleaned up abuses of extern
• cleaned up function pointer correctness in heretic, hexen, might improve portability
• CI improvements: mingw build, cppcheck, linter check
• support for extra mouse buttons (maybe, not sure if existed before and was just fixed) 6e363ea
• was gameversion 1.2 support new or just fixed?
• new icons
• developer only debug things (mempool disable, linked list infinite loop checking)
• windows non-latin fixes Fix memory mapping WAD files on Windows with non-Latin file paths. #1481 Implement M_getenv() wrapper to support non-Latin paths on Windows #1486 Add support for non-latin paths and filenames on Windows #1463
• general compatibility fixes with new compilers (includes, warnings)
• use artifact mouse button (heretic, hexen) Heretic/Hexen: Add mouse button for "use artifact' #1459
• inventory mouse buttons heretic Add heretic mouse inventory buttons #1256 hexen Hexen: Add mouse inventory buttons #1458
• french wads Add detection and search for doom2f.wad and french.deh, respectively. #1418
• mouse button run Add ability to map mouse buttons to run! #1415
• hexen coop demo playback Fix hexen coop demo playback #1382
• support autoloading gog.com releases iwad: Support autoloading GOG.com releases of Heretic and Hexen #1338
• python 2 deprecated, python 3 required build: use python3 exclusively #1330

[rfomin]

• Redesign of native MIDI support in Windows (authors @ceski-1 and @rfomin):
  • Removing the midiproc.exe program.
  • Correct pause/resume.
  • Added support for SysEx messages.
  • Correct reset of MIDI devices using SysEx messages (by @ceski-1).
  • Implement a "capital tone fallback" emulation (by @ceski-1).
  • Add full EMIDI support, looping points (Final Fantasy and RPG Maker) (by @ceski-1).
  • Add MIDI compatibility levels. Emulate Vanilla Doom's DMX MPU-401 mode, Microsoft GS Wavetable Synth or send all messages to MIDI device. Documentation https://gist.github.com/ceski-1/86b7405a66ff67c42a788000edc3b625 (by @ceski-1).
• FluidSynth support implemented (by @mikeday0).
• Support for non-Latin file names in Windows (by @rfomin).
• Support for modern gamepads (by @mikeday0).

Hopefully @ceski-1 and @mikeday0 will add more details.

A few issues:

1. The current chocpkg system does not support FluidSynth. We can build a release for Windows using MSYS2 in GitHub CI.
2. I think we should add support for at least analog turning for the gamepad (analog movement is more controversial).

[mikeday0]

• FluidSynth and gamepad contributions are already mentioned in NEWS.md, so I think we're covered on that.
• Properly handle orphan carriage returns when parsing deh files (by @mikeday0).
• Allow simultaneous PC speaker emulation and OPL emulation (by @mikeday0).

Everything else I did was already mentioned in turol's comment above.

The current chocpkg system does not support FluidSynth. We can build a release for Windows using MSYS2 in GitHub CI.

If we go the GitHub CI MSYS2 route, I suggest waiting for the new release of SDL_Mixer. (I saw somewhere they were doing one this month) It will have a fix for the annoying FLAC looping crash.

I think we should add support for at least analog turning for the gamepad (analog movement is more controversial).

I've got this mostly done, just need to polish. I will submit a PR this weekend.

[mfrancis95]

I'm starting to slowly add what's been mentioned. Feel free to use the suggestion feature to add your lines or add commits to my branch.

[fabiangreffrath]

Please mention the two security fixes that were factored out into 3.0.1, but are if course also fixed in 3.1.0.

[fabiangreffrath]

Please mention the two security fixes that were factor out into 3.0.1, but are if course also fixed in 3.1.0.

One of them was assigned a CVE id, that's important to mention in the changelog.

[mfrancis95]

@fabiangreffrath 3.0.1 added.

[mfrancis95]

Added @fragglet 's NEWS.md additions from last year. @turol judging by git blame it looks like the enum for v1.2 was added pre-3.0.0 but the version didn't gain any actual semblance of emulation until post-3.0.0.

[mfrancis95]

Added more from @turol 's list. Can you expand on the following items as I'm having trouble finding these changes in the code?

• improved portability by allowing disable SDL extra libs
• developer only debug things (mempool disable, linked list infinite loop checking)

and provide commit hashes if you can? It's to help credit people and understand the context. Otherwise, it would be preferable to use the suggestion feature to add those in.

Does anyone know who were all the folks who contributed to the new icons? I see several people possibly involved and it looks like at least one of them has a deleted GitHub account. Just want to make sure credit is given where it's due.

[fabiangreffrath]

Does anyone know who were all the folks who contributed to the new icons? I see several people possibly involved and it looks like at least one of them has a deleted GitHub account. Just want to make sure credit is given where it's due.

The person who left Github was the one who made the current Crispy icons. Their name is Philip Kiwan, but that's all I know unfortunately.

[fabiangreffrath]

Oh, wow, apparently the original contributor of the chocolate bar style icons that are currently used for Chocolate has also disappeared. According to this commit, their user name was @clovehoof:
709862f

[turol]

@mfrancis95 explanations in the PRs:
#1489
#1480

Also re: mingw CI, I only copied that from Crispy Doom so most of the credit probably belongs to @fabiangreffrath

[fabiangreffrath]

Also re: mingw CI, I only copied that from Crispy Doom so most of the credit probably belongs to @fabiangreffrath

Nope, not my work. Please credit @rfomin for this.

[fabiangreffrath]

It is now even possible to bind mouse buttons to turn left/right in all games:
331aed4

[rfomin]

Also re: mingw CI, I only copied that from Crispy Doom so most of the credit probably belongs to @fabiangreffrath

Nope, not my work. Please credit @rfomin for this.

Speaking of mingw CI, I can modify it to publish a release on GitHub like Crispy does.

Pros:

• Newer versions of the compiler and tools
• 64-bit build
• FluidSynth support

Cons:

• We will lose support for Windows XP

[fabiangreffrath]

• We will lose support for Windows XP

I am all for it! Even Microsoft itself gave up support for Windows XP some 10 years ago.

[turol]

@mfrancis95 There are several open PRs ready for review. Do you want to keep master frozen or can I merge them?

[mfrancis95]

@mfrancis95 explanations in the PRs: #1489 #1480

Thanks @turol. Added.

Speaking of mingw CI, I can modify it to publish a release on GitHub like Crispy does.

@rfomin how would you safeguard against having it publish a release for every single commit? I would think we'd only want to have it do this every now and then (but definitely way more frequently than 6 years!)

We will lose support for Windows XP

Another 👍 to deprecating support.

@mfrancis95 There are several open PRs ready for review. Do you want to keep master frozen or can I merge them?

@turol I personally really want to just focus on getting this out the door as-is because more PRs = more changelog additions, but I know that @rfomin and @mikeday0 might be looking to get some changes in, so let me know how you all feel about saving some work for 3.2.0? My open PRs can be ignored -- I still want to test some of mine and I have no issues saving them for the next release.

[rfomin]

@rfomin how would you safeguard against having it publish a release for every single commit?

A release will be published when a new tag is pushed to the repository, this is how it works for the last few Crispy Doom releases. I'll add this code to main.yml: https://github.com/fabiangreffrath/crispy-doom/blob/99416f4be87f1a5eb6e169c670280627284735a9/.github/workflows/msys2.yml#L79-L86

let me know how you all feel about saving some work for 3.2.0?

I agree with @ceski-1, updating the gamepad #1629 is important. If we decide to use GitHub CI for releases, we should also wait for the SDL_mixer update in MSYS2 to fix the FLAC bug.

[fabiangreffrath]

I have no issues saving them for the next release.

I don't think we are in a hurry. We have waited for so long, that it doesn't really make a difference to wait a bit more if this means we can take the opportunities for some real improvements. For me, I'd like to avoid releasing 3.1 today, after 6 year of silence, and 3.2 one week later.

[turol]

Need to mention
#1624
#1630
#1631

[turol]

Some changelog items seem to be missing still.

Which ones? Some of the PRs I asked about were commented as already covered.

[rfomin]

There was something about Windows builds not having up to date libraries. Has this been fixed? If not, what needs to be fixed?

We'll need to update SDL2_Mixer to 2.8.0 in chocpkg.

How about this PR #1643? I think we should use GitHub CI for the release build instead of chocpkg.

Pluses:

• FluidSynth support for Windows and macOS
• SDL_Mixer 2.8.0 already included in MSYS2
• 64-bit build on Windows.

Minuses:

• No Windows XP support

[fabiangreffrath]

Oh yes, forgot about it. Let's do this, please!

[mikeday0]

Does the rpm.spec.in file need attention? The stated dependencies are incorrect. Does anyone still use these? If not, maybe it should be removed.

[turol]

@mfrancis95 May I force push your branch?

[NY00123]

Just heard of a potential release becoming closer.

Hopefully, before that's done, we can have an answer on which variation of Hexen v1.1's behaviors to support.

As a reminder:

• At some point, I modified the released Hexen sources to match the most common executable known as "v1.1". It is also unofficially known as "1.1r1" nowadays. I submitted a PR for Chocolate Hexen and it was accepted.
• Only afterwards, I realized that, in fact, there's also an exe matching the released sources; It's just not commonly known or used. It got a similar (unofficial) title of "1.1r2".
• Therefore, I opened a related issue, and also submitted a PR aiming to re-introduce support for 1.1r2's behaviors in parallel to 1.1r1's.

The main question is, what is to be done for 3.1.0? Revert my change and behave like Chocolate Hexen 3.0.0-3.0.1 (i.e., Hexen 1.1r2), preserve it (1.1r1) or support both variations?

References:
https://doomwiki.org/w/index.php?title=HEXEN.EXE
#1394
#1378
#1266

[fabiangreffrath]

I'd say we should support the new gameversion, but not make it the default. Though, this is apparently exactly what happened when the alternative Final Doom version was introduced:

ed4adeb

[NY00123]

I'd say we should support the new gameversion, but not make it the default. Though, this is apparently exactly what happened when the alternative Final Doom version was introduced:

ed4adeb

Thanks for showing support for having both variations of Hexen 1.1 as options!

It seems that in Final Doom's case, the default was changed to the earlier version more than 6 months later, according to the timestamps of the converted SVN commits: 71d316a

This still differs from the situation with Hexen, as Chocolate Hexen 3.0.1 and earlier should behave like "1.1r2", rather than "1.1r1".

The impacts should still be significantly smaller than in Doom. Apart from changing HEXEN_VERSIONTEXT, there are the A_SoAExplode fixes, impacting demo playback only if monsters are disabled. As in Doom v1.2, I don't think that the demo lumps themselves have a field for the "nomonsters" toggle.

I don't currently have much more to add on 3.1.0 in general. My hunch is that there's more than enough to cover, including but not limited to other improvements to accuracy during gameplay. After 3.1.0 is out, this might also become the standard version of Chocolate Doom for multiplayer, given that a revision differing from 3.0.0 and 3.0.1 has been suggested for a while, if I'm not wrong.

[fabiangreffrath]

We came a good way forward. Any other blockers left?

[turol]

Are all of today's PRs mentioned? In particular the Hexen/Strife desync?

Do we still want to wait for #1665?

[JNechaevsky]

Give me couple of hours please, I was going to do it today, but we have yet another moving of furniture at day job. 🤯

[turol]

There were no objections so I rebased and partially squahed this. Are we still missing something?

[mikeday0]

Still need mention of the last handful of PRs:

• Fix possible Hexen and Strife desync (Michael Day).
• Heretic: Fix null backsector crash (Julia Nechaevskaya).
• Hexen: Add support for two different v1.1 variants through -gameversion argument (@NY00123).

I would like to do some Strife gamepad improvements but that can wait until after the release.

[rfomin]

We need to update the RELEASE_NOTES.md file for the release on GitHub. I suggest just copying the ## 3.1.0 (2024-??-??) section from NEWS.md into it.

[NY00123]

Might PR #1435 impact this? See also the last comment I added over there.

[turol]

@rfomin Updating RELEASE_NOTES.md should be done once just before release so it doesn't accidentally get left incomplete.

@NY00123 I couldn't find a PR for bash completion fix. Do you have it?

[NY00123]

@NY00123 I couldn't find a PR for bash completion fix. Do you have it?

I can't find a clear relevant PR referencing bash completion, either. Maybe @fragglet will recall, being the one to list the fix in PR #1435.

Referencing possible commits:

b9d4c04
96e0123 (probably not that one)
da88012

[fabiangreffrath]

Referencing possible commits:

Pretty sure the last one.

[turol]

If we're happy with the changelog then we should...

1. Pick a release date
2. I'll add it to the changelog and rebase one last time.
3. I'll copy the 3.1.0 stuff to RELEASE_NOTES.md
4. Merge this PR
5. The actual release. What needs to be done to make this happen? Just push a tag?

[rfomin]

5. The actual release. What needs to be done to make this happen? Just push a tag?

Yes, just push a tag. Although it will only be a release on GitHub, not chocolate-doom.org.

[mikeday0]

If we're happy with the changelog then we should...

1. Pick a release date

I am just a humble contributor but I vote next Monday - April Fools' Day. :)

[SoDOOManiac]

Looking forward to this!