PrBoom+ 2.6.66 (Jun 20, 2023)

[Redneckerz]

24 minutes ago, Gregor said:

 

But PrBoom-Plus-um isn't just a fork of PrBoom+ at this point, it's the main branch. Andrey Budko himself declared it the official successor to PrBoom+, right? Does it really matter what it was originally created for? Woof was originally created as WinMBF 64-bit but has moved well beyond that now. Things evolve. PrBoom+um is now seen by most as simply PrBoom+, nothing less. Sure, DSDA has implemented MBF21 but are you saying that DSDA should from here on be considered the new main fork of PrBoom-Plus? I thought DSDA is first and foremost a port for speedrunning and demo recording and doesn't aim to compromise too much on that ground despite all the neat new features.

I thought DSDA is more of a successor of the PrBoom+ Philosophy at this point than PrBoom+um is - Despite the blessing of Entryway declaring um its successor.

 

DSDA's main focus is speedrunning, but because it supports every new modder standard, many drop PrBoom+ for DSDA.

 

So i am rather at Kraflab's here. Prboom+um is more of a classic with UMAPinfo that runs the grunt of new wads these days, and DSDA is its follow up with a focus on speedrunning.

24 minutes ago, Gregor said:

 

On the other hand, PrBoom+um is seen by many as the main alternative to GZDoom. I think, closing or "completing" PrBoom+um at this point would simply alienate a large part of the user base and reduce the adoption of both UMAPINFO and MBF21.

 

There is still the problem that there is no defacto leader. Graf Zahl isn't, Kraflab is more in a maintainer position and also has DSDA under its belt, and Fabian is working on Woof/Crispy.

 

Gibbon, on the other hand, has ReBoom and Pooch. So there is no captain leading the PrBoom+um ship, despite (ironically) being the only port declared its successor by Entryway.

 

If you want PrBoom+ to be a mainstay, it needs an actual developer at the helm. At this stage we should be lucky we still get occassional new um releases.

[GoneAway]

1 hour ago, Gregor said:

Sure, DSDA has implemented MBF21 but are you saying that DSDA should from here on be considered the new main fork of PrBoom-Plus? I thought DSDA is first and foremost a port for speedrunning and demo recording and doesn't aim to compromise too much on that ground despite all the neat new features. On the other hand, PrBoom+um is seen by many as the main alternative to GZDoom.

While dsda-doom is ultimately designed with speedrunning in mind, the features go way beyond just what is relevant for speedrunners. The big advantage prboom+ has at this point is the fact that it doesn't change. I think the main remaining audience of this fork is people that don't know that dsda-doom exists or otherwise prefer to stick with what they know / what works. That's not a shot at prboom+, it's an important and unique characteristic and I still use the port to this day to check things.

 

Seeing as this stability is what is most important and unique for this fork, I'd like to see it remain so. Of course, I would also lament the effort wasted in redundant implementations. A person's efforts could have a much bigger impact in helping with the eternity implementation of mbf21 for instance.

[dew]

From what I've heard, Budko already considered prboom-plus feature-complete back when his interest dropped. True, pr+um shifted this goalpost, but the follow-up development was also greatly motivated by the simple fact that pr+ started bit rotting and people had increasing trouble using or building it.

 

In this light, it would be fair to feature-freeze prboom-plus and only make updates mandated by evolving operating systems - much like chocolate-doom. Then it can work as a baseline for future forks and not a constantly moving target.

 

Spoiler

Not to mention the port itself is kind of, uh, an unwanted orphan. Graf bailed right after his initial commit and never looked back, then fabian and kraflab got entangled via work on their own ports. As far as I know, they'd both prefer chasing their own goals, not backporting ever-more complex features from dsda and woof. I'd say if someone else wants to be that guy, they should welcome having a clear opportunity to fork off from a clearly defined point.

 

Just my 2c, in the end it's always up to the devs anyway.

[Gregor]

2 hours ago, kraflab said:

Seeing as this stability is what is most important and unique for this fork, I'd like to see it remain so. Of course, I would also lament the effort wasted in redundant implementations. A person's efforts could have a much bigger impact in helping with the eternity implementation of mbf21 for instance. 

What difference is there between DSDA and PrBoom-Plus that you're referring to here exactly? Aren't they both just as faithful when it comes to demo compatibility?

And don't get me wrong, i'd personally would have no problem if DSDA were to take up the mantel of PrBoom-Plus so to speak since i already use it as my sourceport of choice anyways. I just doubt that enough people know about it AND are willing to make the switch. Also, just the fact that it doesn't feature "prboom" in its name is enough to put people off from accepting it as the new main branch of PrBoom-Plus; as silly as that may sound. Names are very important to people unfortunately. Boom-->PrBoom-->PrBoom+-->PrBoom+um... DSDA?! ;)

 

EDIT: Maybe you should rename the port to PrBoom+UMDA then. Or PrBoom+DS. ;))

 

Edited October 26, 2021 by Gregor

[Andromeda]

For what it's worth both PrBoom+/UMAPINFO and DSDA-Doom have e6y's blessing as PrBoom+'s successors. Anyway, while I think MBF21 would be a good thing to implement in PrBoom+/UMAPINFO, I can also see it's a hefty task to complete for the programmers who are already pretty busy with their own stuff.

 

29 minutes ago, Gregor said:

What difference is there between DSDA and PrBoom-Plus that you're referring to here exactly? Aren't they both just as faithful when it comes to demo compatibility?

And don't get me wrong, i'd personally would have no problem if DSDA were to take up the mantel of PrBoom-Plus so to speak since i already use it as my sourceport of choice anyways. I just doubt that enough people know about it AND are willing to make the switch. Also, just the fact that it doesn't feature "prboom" in its name is enough to put people off from accepting it as the new main branch of PrBoom-Plus; as silly as that may sound. Names are very important to people unfortunately. Boom-->PrBoom-->PrBoom+-->PrBoom+um... DSDA?! ;)

 

EDIT: Maybe you should rename the port to PrBoom+UMDA then. Or PrBoom+DS. ;))

Renaming makes no sense IMO, since the project's goal is umbilically tied to the Doom Speed Demo Archive. The source-port also doesn't aim to be the new main branch of PrBoom+ as it's targeted for speedrunners first and foremost.

 

Just my two cents anyway, feel free to correct any mistakes/bad assumptions from an outsider's view.

[P41R47]

1 minute ago, Andromeda said:

The source-port also doesn't aim to be the new main branch of PrBoom+ as it's targeted for speedrunners first and foremost.

After reading all the comments, i practically come to think this, too.
And i will add my own experience chatting with people that likes Doom, know about source-ports, but its not a member of the community at all.

The ports is called DSDA-Doom.
It is obviously aimed to the Doom demoing scene.
A casual user out there, or someone here that doesn't research too much, may not think twice about the port, the title will be read and the simple thought would be ''ah, a source-port for speedrunner''.

Simple as that.

And so, many people here, and many people out there, will not even know the huge amount of improvements and features that DSDA-Doom have.
The fact that the new intended modding standar, MBF21, is being mostly developed on a source-port that, for most people out there, is mostly related to demoing, seems quite contradictory, as the demo scene, as large as it is, its not the main scene of the Doom community.
Thus, lots of people will jump onto the other source-port that offers MBF21 and is still pretty much in line with PrBoom+: Woof!

Thats the reason that i found that most people that still plays on PrBoom+, still waits for new releases and wants new features on it.

Another thing that may discourage some is that, in contrast to the other most well known source-ports, even the cutting edge feature wise GZDoom, they all have 32 bits binaries, and DSDA-Doom, still not have an official release made for 32 bit binaries.
This should be important, as i know many players that are speedrunner that don't even have a 64 bits PC to run DSDA-Doom, and for that reason and not knowing that Woof is also pretty much perfect for demoing, they still use PrBoom+ and want more improvements and features on it.

[Gregor]

1 hour ago, Andromeda said:

Renaming makes no sense IMO, since the project's goal is umbilically tied to the Doom Speed Demo Archive. The source-port also doesn't aim to be the new main branch of PrBoom+ as it's targeted for speedrunners first and foremost.

 

Well, whether or not DSDA is in the name wouldn't really change that much for its appeal as a speedrunning port. The appeal is in its functionality.

 

4 hours ago, kraflab said:

While dsda-doom is ultimately designed with speedrunning in mind, the features go way beyond just what is relevant for speedrunners.

 

On the other hand, adopting the "PrBoom" name would recognizably tie the port to the Boom heritage and would help to mark it in people's minds as an official successor in that line if that is the direction @kraflab wants to take it. If you want to broaden the reach of something don't underestimate just how important names can be. It's the very reason franchises are kept going rather that new IPs being developed in the video gaming or movie industry.

 

Boom is such a big name in the community that simply carrying in it in the title transfers authority to that sourceport. And since DSDA very much IS a successor to PrBoom+ you could argue that it is actually kinda held back by its name. If DSDA wants to be the leading branch of PrBoom+ AND wants more people to switch over to it then adopting the PrBoom name in some form might not be such a bad idea.

 

That or we need to get decino to switch over to DSDA and fire up the hype train for it on Youtube. ;)

Edited October 26, 2021 by Gregor

[GoneAway]

Guessing you all didn't follow the "what source port do you use" poll, since dsda had a higher result than prboom+. 😛

 

That's not important to the question of whether prboom+ should implement new standards or what the end goal of the port is, but let's not pretend dsda-doom is some overlooked port that is flying under the radar. My goal isn't to increase "market share" or be the successor of anything though. After heretic and hexen were implemented, and with the work ongoing now, the port itself is quite far away from prboom+ in the code, although the familiar interface remains. And this is also the "downside" to dsda-doom, because I'm willing to completely break things and strip down and rebuild things. Sometimes features disappear or change in ways not every player will like.

[Doomkid]

10 hours ago, kraflab said:

I think it's time to think of prboom+ as a "complete" time capsule and not something that needs to keep evolving.

I was honestly kind of hoping this would be the case once DSDA-Doom hit the scene. Just chiming in as a voice of agreement, a 'like' didn't feel good enough.

 

3 hours ago, dew said:

In this light, it would be fair to feature-freeze prboom-plus and only make updates mandated by evolving operating systems - much like chocolate-doom. Then it can work as a baseline for future forks and not a constantly moving target.

Again, just quoting in support of this idea.

[HackNeyed]

3 hours ago, P41R47 said:

It is obviously aimed to the Doom demoing scene.

 

It probably doesn't help visibility that the DSDA-Doom thread is in the Speed Demo section and not in the Source Port forum either.

 

3 hours ago, P41R47 said:

Thus, lots of people will jump onto the other source-port that offers MBF21 and is still pretty much in line with PrBoom+: Woof!

 

That's where I'm kind of at.

 

I don't know who else feels this way or how much it really matters but...

 

I want a demo compatible engine with wallrunning, key grab etc. (PrBoomUM, DSDA, Woof). Cosmetic bug fixes and enhancements that are in official game re-releases or should have been like the ouch face, transparency for sprites, color blood, blazing doors, kill totals etc. (PrBoomUM, Woof and kind of DSDA I mean it has some and dehacked can add others but no Ouch Face... Could it be exposed to dehacked fixing? Woof doesn't have HD rendering which is nice for highly detailed wads). Then there are quality of life things like key customization, binding to mouse, double binding etc. (DSDA, Woof and apart from the double binds that I require PrBoomUM). Lastly there is MBF21 support. I believe it should be the future of Doom modding and demoing and I wish it had happened at least 10 to 15 years ago. GZDoom is fantastic but it is not a Doom engine. It is an engine that plays Doom and I have little interest outside of classic-ish Doom, Boom, MBF and MBF21.

 

So this all leaves me with Woof to play and record on complevels 2,3,4,9 and 11 with a few autoloads for sprite fixes and umapinfo. I don't think I really want to setup DSDA-Doom with a bunch of options.lmps for Vanilla and Boom behavior and dehacks for transparency on top of the sprite fixes so I can play and record BTSX in MBF21 format for myself. I know I'd be disqualified by using the transparency dehack alone so I won't really be submitting my casual demos anywhere anyway I'd just like to use an updated PrBoomUM or Woof going forward. 

 

Speaking of just playing in MBF21. I like the idea of Automatic Compatibility for broken maps in DSDA-Doom but who is this for? The casual player who doesn't know that DSDA-Doom exists or the casual player who can't find the color blood or ouch face option etc and just goes back to GZDoom. If you are recording demos to submit you are not that casual and you are locked to strict complevels anyway, right?

 

Speaking of, I love the idea of a strict mode to disable TAS features for comparing and competing demos. I wish that could be extended to cosmetics so there could be some fixes but I know that's not happening. The rewind feature is GREAT and I will mostly be watching demos in DSDA-Doom but I'm going to play and record in the most comfortable and visually consistent engine that I can find. I don't mind a bit of toggle options and I was hoping PrBoomUM would catch up with double binding and MBF21 so I could use it or Woof since they offer the cosmetics I'm used to and the compatibility that I expect. DSDA-Doom is just not that interesting for me and that's ok.

 

I know DSDA-Doom is not a democracy and of course that's fine but that only means people might want another port more aligned with what they want. PrBoomUM has been a catch all for the space within complete demo compatibility and modern enhancements and comfort. DSDA-Doom is intentionally staying behind in some areas (remaining pure). PrBoomUM is unintentionally left behind in other arguably more important areas. I may be alone in most of my thoughts but at least there is Woof. I wasn't going to say so much because, well, who am I? An oddly specific casual. But if we are talking about PrBoom casuals well these are my thoughts. 

Edited October 27, 2021 by HackNeyed
typos

[Gregor]

2 hours ago, HackNeyed said:

PrBoomUM is unintentionally left behind in other arguably more important areas.

 

Not unintentionally as you can see from the preceding posts. It's very much a conscious decision to not implement any further new features into PrBoom+um at this point.

I agree with most of what you wrote. A lot of people will stick with Prboom+um because that it is what they know and are comfortable with but also because until now it was the best compromise when it comes to Boom/MBF-compatible source ports as neither DSDA nor Woof offer the same level player friendliness. DSDA is pretty radical in the way certain features are cut completely which is sure to alienate some players. And Woof still sticks to the 640x480 limit and that alone is already a major turn-off to most "casual" players.

 

I was really hoping MBF21 would be implemented across the board so we could finally move beyond this broken-up sourceport landscape where every fork has its own unique features, for its own small user base and there's no real compatibility for any newer features past Boom/MBF (which is crazy to think after over 20 years). Now with PrBoom+um left out it removes one of the major players and that only weakens the potential appeal for MBF21 IMO. But i guess there will always be GZDoom at least. 😅

 

EDIT: I guess i can also update the wiki then. It still lists PrBoom+um among those sourceports who are committed to implementing MBF21. That's why i thought those features would be coming in the first place. So apparently that was on the agenda at some point at least.

Edited October 27, 2021 by Gregor

[Redneckerz]

5 hours ago, P41R47 said:

Another thing that may discourage some is that, in contrast to the other most well known source-ports, even the cutting edge feature wise GZDoom, they all have 32 bits binaries, and DSDA-Doom, still not have an official release made for 32 bit binaries.

GZDoom's recent 32 bit binary is temporary: 4.7.1 will be the last.

5 hours ago, P41R47 said:

This should be important, as i know many players that are speedrunner that don't even have a 64 bits PC to run DSDA-Doom, and for that reason and not knowing that Woof is also pretty much perfect for demoing, they still use PrBoom+ and want more improvements and features on it.

You know, i find this strange and i like more clarity on this. 64 bit Windows and PC's have been around since 2004-2005. Are you to tell me that many speedrunner users do their thing on hardware that is the equivalent of a Pentium 4/Athlon 64, with the bare minimum OS being Windows XP 64-bit?

 

Even in countries where computing resources are more expensive than elsewhere and usually not very available for these users, i find it difficult to believe that many speedrunners only have access to 15 year old tech.

 

GZDoom's 32 bit support is a one off because virtually no-one has a 32 bit machine anymore - Gibbon's line of work is 64-bit only.

 

What is the usersize of speedrunners who run this standard of hardware and who for the life cannot upgrade to literally anything else that has 64 bit supporr?

[rfomin]

1 hour ago, Gregor said:

Not unintentionally as you can see from the preceding posts. It's very much a conscious decision to not implement any further new features into PrBoom+um at this point.

This is not a "conscious decision", it's just a hobby for us, and doing the same job twice is not very interesting, especially when DSDA-Doom exists. If you need MBF21 in PrBoom+ you are welcome to try, Kraflab has written excellent documentation: https://github.com/kraflab/mbf21

[Gregor]

7 hours ago, HackNeyed said:

Cosmetic bug fixes and enhancements that are in official game re-releases or should have been like the ouch face, transparency for sprites, color blood, blazing doors, kill totals etc. (PrBoomUM, Woof and kind of DSDA I mean it has some and dehacked can add others but no Ouch Face...

The Ouch face is fixed in DSDA-Doom on higher complevels. Just like the sound clipping bug.

 

 

3 hours ago, rfomin said:

This is not a "conscious decision", it's just a hobby for us, and doing the same job twice is not very interesting, especially when DSDA-Doom exists. If you need MBF21 in PrBoom+ you are welcome to try, Kraflab has written excellent documentation: https://github.com/kraflab/mbf21

It is a "conscious" aka deliberate decision as opposed to something that happened by accident. But that's fine. I understand the reasoning behind it. I think it's a bit of a shame. But it's no big deal in the end.  I got hyped when i saw the wiki page listing pretty much every major sourceport under those that will implement MBF21 including PrBoom+um. That's why i was a bit disappointed when it turned out that that was erroneous information. I do think PrBoom+ needs MBF21 but unfortunately i cannot program myself. It's all good though. I'm sorry if i upset you.

Edited October 27, 2021 by Gregor

[Redneckerz]

MBF21 was indeed planned. As it stands PrBoom+um should be considered to exist on a maintenance state - Bugfixes, formost, but no new features unless someone takes over.

 

Perhaps the PrBoom+ page should reflect this, given the confusion.

 

Shameless plug aswell to fill in the details regarding these details there: i am unable/too unknowledgeable about the finer details that belie MBF21, DEHEXTRA or DSDHacked.

[Spectre01]

What are the challenges associated with implementing MBF21 in PRBoom+? Wouldn't the DSDA-Doom code be nearly identical since the ports are so similar?

[fran]

9 minutes ago, Spectre01 said:

What are the challenges associated with implementing MBF21 in PRBoom+? Wouldn't the DSDA-Doom code be nearly identical since the ports are so similar?

 

Why implement something that nobody is going to be responsible for maintaining?

 

mbf21 standard has been evolving (it is currently in version 1.4) and its implementation in woof, to give an example, has required constant monitoring and bug-fixes by its developers.

 

The target user of prboom-plus is someone who wants something stable (that's why it's the demo playback souce port par excelence).

[HackNeyed]

4 hours ago, Gregor said:

The Ouch face is fixed in DSDA-Doom on higher complevels. Just like the sound clipping bug.

 

Yeah thanks but the lower levels are missing a cool feature and the lack of consistency is what really annoys me. I used to only use the Boom HUD years ago because I didn't like wads changing the status bar. I could always copy the regular face over the ouch face and put it in the autoload to disable it. haha oh well.

[GoneAway]

8 hours ago, HackNeyed said:

I like the idea of Automatic Compatibility for broken maps in DSDA-Doom but who is this for? The casual player who doesn't know that DSDA-Doom exists or the casual player who can't find the color blood or ouch face option etc and just goes back to GZDoom. If you are recording demos to submit you are not that casual and you are locked to strict complevels anyway, right?

I know my audience better than you do. It's important to not fall into the trap of thinking one's personal experience and specific niche desires for a port are in any way related to what the wider community needs or wants. "I want to play on a custom complevel that is somewhere in between complevel 2 and complevel 11" is an extreme niche. It's way more likely that such a person opens the port without knowing what a complevel is. And someone wanting to design a custom experience like that is usually the type of person that is happy to configure details. The port is set up so that it can be customized and that customization can be easily shared - someone can create the necessary files and distribute them (as opposed to having everything in menus and one config file, where sharing the files would overwrite your settings). Eventually there will be configuration profiles baked in that cover these niches as well.

 

DSDA-Doom is currently being designed with 2 key groups in mind: people looking for the competitive environment (not just speedrunners - some people like getting the tailored experience of what is considered authentic / legitimate to that scene), and people that just want to pick up and play. Right now dsda-doom provides improvements for both groups. Obviously there's a long way to go still for the second group.

 

You have to keep in mind that I can't do everything at once. DSDA-Doom is two thousand commits ahead of prboom+ right now. My focus over the past year has been to provide a fair environment for speedrunning and create a heretic / hexen port that has the feature scope of prboom+. Sometimes cutting or ignoring features to simplify the code base is the sane option when you're looking at incorporating hundreds of thousands of lines of code into your port :^)

 

6 hours ago, Gregor said:

I was really hoping MBF21 would be implemented across the board so we could finally move beyond this broken-up sourceport landscape where every fork has its own unique features, for its own small user base and there's no real compatibility for any newer features past Boom/MBF (which is crazy to think after over 20 years).

The assumptions here are that prboom+ remains as big as it always has been, that all the users of prboom+ are users that want to play wads with advanced features, and that those advanced features are port-specific. All of those assumptions are wrong. There's a new standard that is compatible with flavors of prboom+, crispy, zdoom, and (eventually) eternity. You're going to ignore this because every version of every port doesn't implement it?

[Gregor]

59 minutes ago, kraflab said:

The assumptions here are that prboom+ remains as big as it always has been, that all the users of prboom+ are users that want to play wads with advanced features, and that those advanced features are port-specific. All of those assumptions are wrong. There's a new standard that is compatible with flavors of prboom+, crispy, zdoom, and (eventually) eternity. You're going to ignore this because every version of every port doesn't implement it?

Fair enough. I'm sure you have a better overview of these things than me. I'm just voicing my concerns. People tend to be reluctant to change and rather pass on something new and advanced if it requires them to inconvenience themselves with switching to something they are not familiar with. That's just basic human psychology. There's always a wish to have everything in one place, one application, one system and stick with what is familiar rather than adapting to something new. That's why most gamers prefer consoles over PCs. And most PC gamer prefer Windows over Linux, and so... Anyways, i suppose most of my concerns are unfounded. It will most likely work out just fine. Let's face it, the overwhelming majority of casual gamers that stumble into Doom are not gonna move beyond GZDoom anyhow. And for good reasons. ;)

[Kappa971]

I would like to share my personal opinion on Doom's source ports. Let me be clear, I don't want to offend anyone and I believe that the work you do is extraordinary.

In a word it could be defined as "Chaos"...

Perhaps the most discredited and attacked port is GZDoom for its being inaccurate compared to the original Doom (I also like more accurate ports), but in my opinion it is the most complete Doom source port around, perhaps for the simple fact that for each new feature, a fork is not created but rather implemented in GZDoom. Here this in my opinion is the problem of Doom's ports, forks.

Let's talk for example about PrBoom-plus, ok it doesn't have an active developer but why are PrBoom-plus forks created when those functions could be implemented in PrBoom-plus? And I don't think anyone would have complained. We are talking about the new MBF21 standard with which perhaps new maps and wads will be created, but it is a feature that PrBoom-plus will not have and therefore in the future this port will be "useless".

I conclude by saying that if you developers concentrated your efforts in a single source port (such as PrBoom-plus) without creating a new fork for each new feature, there would not be all this chaos. 

Thanks for reading and I apologize for any errors :)

Edited October 27, 2021 by Kappa971

[HackNeyed]

3 hours ago, kraflab said:

I know my audience better than you do. It's important to not fall into the trap of thinking one's personal experience and specific niche desires for a port are in any way related to what the wider community needs or wants. "I want to play on a custom complevel that is somewhere in between complevel 2 and complevel 11" is an extreme niche. ... ... ...

 

Thank you for the reply. It is definitely nice to hear a bit more perspective on what's going on in your vision and what your plans are for the port. I am sorry I was overly harsh in my critique of DSDA-Doom. I really do like the things you are adding and working on but I also really liked the stuff you've been cutting away. I only meant to illustrate that as a user I, and maybe others are beginning to face an almost contradictory divergence.

 

Woof started with a very simple niche goal; to be old school MBF on modern hardware. Now it has grown beautifully and added many great features making it a very strong modern choice (compatibility, cosmetics, MBF21!). That being said it will remain by design an incomplete PrBoom+UM replacement (no HD, no TAS fast forwarding, no whatever else). I actually agree with most of it pretty strongly.

 

The reason I compared and contrasted so heavily with DSDA-Doom and felt the disappointment so strongly is because DSDA-Doom WAS PrBoom+UM and PrBoom+UM had these things that I liked. I believe DSDA-Doom should be the Official continuation since demos were always the core of PrBoom-Plus. You have been adding and growing this port in all the amazing ways that PrBoom-Plus should have been doing since development ceased 5 years ago and then some. But I understand that this is not an entirely fair comparison. DSDA-Doom is it's own thing and it can and should remove things inherited from the parent port to better fit it's own vision and purpose... I didn't mean to bite my bitter pill at you. I was just trying to make a case for PrBoom+UM against the mounting certainty of its demise and the fractured nature of it's almost but not quite feature complete replacements.

 

3 hours ago, kraflab said:

DSDA-Doom is currently being designed with 2 key groups in mind: people looking for the competitive environment (not just speedrunners - some people like getting the tailored experience of what is considered authentic / legitimate to that scene), and people that just want to pick up and play. Right now dsda-doom provides improvements for both groups. Obviously there's a long way to go still for the second group.

 

Yes this is also to my point about the "between complevels". A complevel fundamentally needs to be a standard of engine functions to allow a map (or demo) to be completed as intended. Anything outside of that is optional.  This is your second group. But it can also be a leveling ground, a standard of play and an experience as you've put it. That would be your first group.

 

As I've said in the other topic I really like the idea of Automatic Compatibility for the pick up and play types. I too have lamented personally the lack of included option lumps that could just force the correct complevel for play and recording. Why wasn't that a standard years ago?! Profiles and drop in databases would be very cool and help reach a wider audience. I just hope they are willing to look and able to find DSDA-Doom. It must be an interesting tight rope to walk catering to the hardcore and the most casual of casuals. Again pardon me for being a little lost in the middle.

 

3 hours ago, kraflab said:

You have to keep in mind that I can't do everything at once. DSDA-Doom is two thousand commits ahead of prboom+ right now. My focus over the past year has been to provide a fair environment for speedrunning and create a heretic / hexen port that has the feature scope of prboom+.

 

Yep, understood. Thank you for your work and thanks again for taking the time listen and to share your thoughts!

Edited October 27, 2021 by HackNeyed

[GoneAway]

GZDoom is a fork too :^)

 

For the question of "why not implement everything in one port" consider this: you see someone has built a nice house. You'd like the house to have a different coat of paint, and also have an extra wing added on the side, plus build a pool in back. And sometimes you actually want to remove one of the rooms and add a patio instead. But someone owns the port and decides the vision and direction, it isn't a free for all. It's natural that different people will have different visions - when the vision is strong enough a new port is born!

 

GZDoom's vision is to run as many things as possible and be a generic platform for building all kinds of different games and experiences, even translating from other formats into its own when loading levels. That vision produces a great experience a lot of times, but it has its own downsides and complications. For example, the port isn't demo compatible with vanilla and isn't compatible with its own past versions. If someone's concern is absolute compatibility with the engine, gzdoom "fails" rather than succeeds. There are wads you can't finish in gzdoom, so it doesn't actually do everything. By embracing more features, it had to sacrifice others. As Graf has mentioned in other places, it also results in a lot of complications and technical debt in the code base. If someone tried to combine all the ports (even, for instance, just combining gzdoom and eternity), then you would see real chaos. Most likely it would be a broken mess. Sometimes visions are definitively incompatible.

[Gez]

39 minutes ago, Kappa971 said:

perhaps for the simple fact that for each new feature, a fork is not created but rather implemented in GZDoom

That's not entirely true, GZDoom has its own share of forks; however they're usually tied to specific projects rather than being new forks for the sake of being new forks. Though there's been a few of those, too.

 

The problem for PrBoom is that part of its mission statement is to maintain backward demo compatibility. So every new feature, every change, must be validated and tested for regression. This can represent a lot of extra work! Pr+um went through several rounds of bug fixes to restore the expected capacity to play back demos. ZDoom, by deciding early on that it didn't care about this aspect any more than id Software themselves did, has been free to make sweeping changes and refactors that are an integral part of its success -- but also of its criticism.

 

When you look at it this way, why should Alice accept to implement Bob's code in AliceBoom+ when all the work of validating Bob's code would fall upon Alice? Alice may have her own changes she wants to make instead! Inversely, why should Bob accept to implement Alice's code in PrBob+ when he could instead be working on what he wants to do? (Alice and Bob used instead of specific people because it's the principle of the thing.)

 

Basically it's a question of compromise. There's always stuff you have to sacrifice somewhere. Even if you decide you won't sacrifice anything and will just put every port in existence in a blend-o-matic to make the One Port To Rule Them All, you'll have to sacrifice something. Maybe not a feature, but definitely a lot of time, and a lot of legibility in the code...

Edited October 27, 2021 by Gez

[Kappa971]

I think, for example, DSDA-Doom could very well have been PrBoom-plus 3.0, I see no features in contrast to PrBoom-plus and as someone said, PrBoom-plus doesn't have a main maintainer so no one would object to such changes.
At present, PrBoom-plus could become DSDA-Doom's "Debian Linux", ie add functionality to PrBoom-plus only when they are complete and stable enough. Otherwise PrBoom-plus will be yet another Doom port no longer developed by anyone and at that point we might as well close the project now and focus only on DSDA-Doom.

[GoneAway]

11 minutes ago, Kappa971 said:

I think, for example, DSDA-Doom could very well have been PrBoom-plus 3.0, I see no features in contrast to PrBoom-plus and as someone said, PrBoom-plus doesn't have a main maintainer so no one would object to such changes.

There are all kinds of decisions I made in dsda-doom that would never be made in prboom+. There is some overlap in key elements, and one is a fork of the other, but otherwise they are not the same port and don't have the same vision. And I don't think it's right to take over someone else's port anyway, regardless of a lack of objection from anyone.

 

24 minutes ago, Kappa971 said:

Otherwise PrBoom-plus will be yet another Doom port no longer developed by anyone and at that point we might as well close the project now

It has already been in a maintenance mode + small quality of life changes for a long time. This isn't anything new and hasn't been a problem yet, so I don't see why it would become a problem now.

[JadingTsunami]

The players want new PrBoom+ features because they trust it and it feels familiar, the developers want to work on their own ports because it gives them personal freedom and control over what features are in or out.

 

PrBoom+'s original developers are not active anymore. This is why there is no MBF21 support. No one wants to invest such a large amount of time and energy in a port they don't control.

[Kappa971]

The implementation of MBF21, due to the fact that it could become a standard, I think it is mandatory to not make the port obsolete in the near future. This at least is a suggestion.

Otherwise I repeat, if no further developments are planned, it is better to focus on DSDA-Doom and close the project, as PrBoom-plus would have nothing more to say and could become incompatible with the new wads.

15 minutes ago, kraflab said:

And I don't think it's right to take over someone else's port anyway, regardless of a lack of objection from anyone.

From what has been said, currently PrBoom-plus is not maintained by anyone but by "volunteers" so I don't see what the problem would have been :)

Edited October 27, 2021 by Kappa971

[GoneAway]

1 minute ago, Kappa971 said:

The implementation of MBF21, due to the fact that it could become a standard, I think it is mandatory not to make the port obsolete in the near future.

And yet chocolate doom, crispy doom, zdoom, etc are not obsolete yet. Many people continue to use these ports. It will be the same for prboom+ 😉

[Kappa971]

18 minutes ago, kraflab said:

And yet chocolate doom, crispy doom, zdoom, etc are not obsolete yet. Many people continue to use these ports. It will be the same for prboom+ 😉

Chocolate Doom and Crispy Doom are not comparable to PrBoom-plus as the former can only support vanilla Doom compatible wads, the latter the same but also those that exceed the limits of the original engine. Neither is meant to support other types of wads.

ZDoom is an obsolete Port, it hasn't been in development for a few years so it doesn't have the latest features, but then PrBoom-plus should go the same way.

Edited October 27, 2021 by Kappa971