PrBoom+ 2.6.66 (Jun 20, 2023)

I agree with Seed here - the time needed to patch the current sound code can better be used to prepare GZDoom's code for inclusion. In fact I already managed to compile ZMusic to a DLL. If someone wants to help here, a better investment would be to set up its CMake project to compile and produce proper binaries on Linux and macOS. I'm currently busy preparing GZDoom's next release so if this could be done in parallel, that'd really advance matters.

https://github.com/coelckers/ZMusic

If someone is interested, please ask for access. If you want to integrate it into other ports, you are welcome, if someone wants to add other music formats or players, even better.

The library itself is C++, but the API is plain C and deliberately kept minimal, although not tested in a C enviroment yet.

There's two variants of the library, one fully GPLv3, the other LGPLv2, but it excludes most of the MIDI backends which depend on GPL code.

I'll make an announcement thread once I'm through with the GZDoom release.

I want to attract attention to something extremely important:

https://doomwiki.org/wiki/DMAPINFO

This page was created by @sponge, so it's serious. We actually have an official id-Software MAPINFO standard now. It's very close to the modern ZDoom format, though with some interesting differences and additions.

Looks they took ZDoom as an inspiration here, too bad that now we got yet another standard(TM)...

The differences in there actually concern precisely the parts where ZDoom screwed up, so it's understandable that they didn't copy it.

(sighs) and no terminators again, and no delimiters in "endsequence" text...

Yes, that was stupid. It seems their parser decides by token type what to do. I cannot say I like that decision.

Yea, I wasn't wanting to make a new standard so I stuck with the new ZDoom almost-INI style, but when I got to the point where I'd have to implement the cluster stuff, I veered off there. It seemed kinda confusing just for the use case of triggering episode scrollers compared to just saying "use the text screen next". We don't use lumps for "entering level" graphics and level names and such, they're rendered out as strings in Unity, so some stuff like that differs. This was something we needed to support add-ons overriding map names and populate them in the UI in the level select, it was very much the quickest way to get what we wanted, hence using a new prefix. 

I'm theoretically not against supporting a subset of UMAPINFO or something like it in an update, I just didn't know its existence until it was too late and based on a quick search, I wasn't clear what the working status of it was.

I don't expect DMAPINFO to be the end all be all or anything, it is just a means to an end.

The most critical thing on the parser side is the lack of separators between the string lines of the end-of-game text - that one could be a problem for some of the parsers. It certainly would require special treatment in GZDoom's. If it followed the same rule as ZMAPINFO, i.e. separating all parameters by comma - and ending one instruction when no more commas follow, that alone would help a lot, I think, because then it could be parsed with a formal grammar far more easily.

You think you can include support for demos made in MBF v2.04? Vanilla PrBoom-Plus (lol) is missing that feature.

Support for the alternate Final Doom exe via -complevel 4 would also be a nice change (much like how there's a command line switch for -complevel 11 that fixes the 3 keys bug... though I forgot what it was)

Looks like there's interest to make this version of PrBoom+ official!

Great news: https://github.com/coelckers/prboom-plus/issues/41

Yes, that was a nice surprise. And getting PrBoom of that cesspool called Sourceforge for good would be the icing on the cake.

I'll really have to get to the sound system workover, but before that have to take care of another non-Doom related project that's currently keeping me busy. But once that's out of the gate I'll invest some work here for sure.

wow. that might give it a momentum and much needed PR. i guess that when everything will be done (those organisational things), you should make Teh Official Announce Thread, or something, so people will know that it is The Blessed One now.

1 hour ago, Ferk said:

Looks like there's interest to make this version of PrBoom+ official!

Great news: https://github.com/coelckers/prboom-plus/issues/41

Fuck yes, this is such great news :).

I can't wait for this to get more recognition, and after the sound update I think it'll get quite a nice boost.

Oh hell yes! Proff is back and is interested in this. Great news!

The latest git version of prb+ 2.5.1.7 (commit 5679359) desyncs while playing back some Eviternity and Valiant (both are cl11 wads) demos, e.g. evit30-250, evit24-832, va18-931, va24-1143. Both the evit30 demo and the va24 max have different rng from the very beginning (and evit30 cannot be finished at all in 2.5.1.7 for some reason). Unfortunately I don't have enough time currently to investigate the causes.

Also a fix of R_PointOnSide for clang on macOS and Linux can be adapted from Eternity.

I'm a bit confused about 2.5.1.7's aims. What are the intentions for stuff to be added before release? I thought this was supposed to be just UMAPINFO and UMAPINFO-related features for the initial release, then expanding scope afterwards for later releases?

As for Proff's suggestions for a PRBoom+ org, I like the idea, but who would be part of such an organisation?

On 1/12/2020 at 8:34 PM, vita said:

The latest git version of prb+ 2.5.1.7 (commit 5679359) desyncs while playing back some Eviternity and Valiant (both are cl11 wads) demos, e.g. evit30-250, evit24-832, va18-931, va24-1143. Both the evit30 demo and the va24 max have different rng from the very beginning (and evit30 cannot be finished at all in 2.5.1.7 for some reason). Unfortunately I don't have enough time currently to investigate the causes.

Turns out this was my fault, no reason to pick on Graf. The pull request to fix this has just been merged.

So this is the commit that broke sync? Good thing there wasn't a release made back then after all.

This, and the fact that dog support was accidentally kicked out when switching to CMake. Right after this commit the code was still consistent. 

Perhaps the worst timing for this but ill just bring it up for the sake of it:

There was a portname thread last year -

@Graf Zahl suggested Omega, @Linguica went with Proboom and @seed suggested UBoom/UBoom+.

Have we reached some consensus in this? Because the current name sake is not really a proper name (It writes out as PrBoom+UM. Which, um.... is not that glamorous.)

I still think UBoom+ is the best option, and I've already started referring to Graf's fork as such :p.

I too think UBoom (short for Ultimate Boom) is the best name. The name is a jab at Ultimate Doom and it also has "Boom" which denotes the Boom ancestry.

Omega and ProBoom are nice as well tho.

UBoom+ looks nice.

How about Bang because Bang Boom Bang

Pistache Boom

+1 for UBoom. Not UBoom+ tho, because that implies there is already a UBoom which has been somehow improved upon.

i was missing this "name talking". welcome back.

Nah, if we get a new name it should be

"The Ultimate PrBoom++"

:D

ProBoom Plus Ultra!

Go Beyond™.

If Proff agrees just PrBoom.

Super Ultimate PrBoom++ Turbo 2020 DX Ultra! Redux HD: Re-emergence - Definitive Edition