Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
fabian

PrBoom+ 2.6.66 (Jun 20, 2023)

Recommended Posts

10 hours ago, Redneckerz said:

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

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?

The thing is not if there are people that need it, the thing is that the option should be there because there are still lots of system out there that are 32 bits.
Not all the PC users are tech savvy, they just bought the computer and want to use it. And so, they didn't know what they have, and usually, they are old 32 bits setups.
Believe it or not, in my country, 32 bits is far cheaper than 64 bits, and so, lots of people still buy 32 bits versions of Win.


You should know that there are also countless of people out there making old computers with old systems everytime, even when they can afford newer models and hardware, and theu just do it because they want.
That includes 32 bits OSs.

Man, if you know the financial incomes of the other countries you wouldn't be talking about PC from 15 or more years old.
You talk from your experience, i talk from mine, and i can tell you, i know far more people with old systems than newer ones.
Why? Because to my country comes all the leftovers that weren't sold on other countries.
And so, laptops and PC with old and legacy OS are sold like they were the new and shiny ultimate model on the market, even today.
And people that don't know a damn thing about PC, but needs a PC, exist.
This the case of lots of people i know.
And what they do? They upgrade just because a game has more pre-requisites to be played?
No, they use what they have until it brokes, and then, if they have the money or really needs a new one for working or other things, they buy a new one.
And what do you think they will buy?
Something that is far more expensive because its new or better? Or will buy something they can afford but is old and maybe even deprecated, but still works for most of the normal things they could need it?
If you need numbers, the monthly money income of a normal middle class worker here is between $25.000 to $70.000 pesos argentinos.
They need to use that for food, rent and different services.
A good PC, with all the newer resource sold at dollar price (because thats the catch), cost from $100.000 to $300.000 pesos.
Old hardware and old laptops that are sold as secondhand cost around $30.000.
How many month of your complete income do you think one person needs to save to be able to buy a good PC nowdays?
Miracle of humanity, credits cards exist, and some can afford a better system.
But the rest?
The answer is simple, they bought what they can afford, and live with it.
Usually, 32 bits systems.

The dedicated player base is really small here, its far bigger than what it was when i was a kid, but is still really small in comparison to other countries, and so, just a few can have proper systems as nowdays gaming require.

Share this post


Link to post
32 minutes ago, JadingTsunami said:

No one wants to invest such a large amount of time and energy in a port they don't control.

This is a critical point to make. Even GZDoom more or less forked out rather than take over ZDoom - which got frozen eventually. I seriously doubt any of the pr+ devs feels like they're "the new team", that dynamic is strained and the leaders of the effort clearly think of it in caretaker terms. Why would you endlessly cultivate your neighbour's garden when they moved away and there's work to be done on your own?  It's up to the new owner of the garden.

 

15 minutes ago, Kappa971 said:

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.

Then who is to say prboom-plus is supposed to support wads of a newly introduced standard? After all, it doesn't support already existing standards, like Zdoom, so it's hardly a play-all option in the first place.

 

1 hour ago, Gez said:

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.)

Yet you namedrop @Bob9001's soon to be announced port that will reshape the world and make the others obsolete. Curious!

Share this post


Link to post
5 minutes ago, dew said:

Then who is to say prboom-plus is supposed to support wads of a newly introduced standard? After all, it doesn't support already existing standards, like Zdoom, so it's hardly a play-all option in the first place.

Then MBF21 is not a standard ;)

Share this post


Link to post
21 minutes ago, Kappa971 said:

ZDoom is an obsolete Port

Is it?

 

DBK02: The DBK Christmas Special

by @Big Ol Billy » Tue Oct 26, 2021

Quote

1. Target compatibility is ZDoom 2.8.1

If people are still deliberately targeting ZDoom compatibility for new projects in late 2021, it's that the port is not that obsolete.

 

Or by that token we could say that Doom itself is obsolete. After all, id Software superseded it with a new Doom in 2016... And yet I bet there's more people playing Doom 1993 than playing Doom 2016 right now.

 

 

4 minutes ago, Kappa971 said:

Then MBF21 is not a standard ;)

A standard doesn't need universal adoption to be a standard.

Share this post


Link to post

Zdoom is reserved for Zdoom/GZdoom, MBF21 should become a "universal" standard but if famous ports like PrBoom-plus don't adopt it, then it's not a standard.

 

4 minutes ago, Gez said:

If people are still deliberately targeting ZDoom compatibility for new projects in late 2021, it's that the port is not that obsolete.

In life there is always some exception :)

4 minutes ago, Gez said:

A standard doesn't need universal adoption to be a standard

But it is his goal otherwise a standard would have no reason to exist.

Share this post


Link to post

There are plenty of reasons for non-universal standards to exist.

 

UDMF is a standard, too. Has it been adopted by PrBoom+? No.

Share this post


Link to post
48 minutes ago, Gez said:

 

UDMF is a standard, too. Has it been adopted by PrBoom+? No.

This does not mean that past mistakes need to be repeated

 

In any case, I conclude by saying that if no new features are planned in PrBoom-plus, at this point it is wiser to close the project and continue the development in DSDA-Doom (as it was done with ZDoom and the continuation of the project in GZDoom).

Edited by Kappa971

Share this post


Link to post

Getting kind annoyed by the tone setting of some here. You can't have the cake (PrBoom+um) and eat it too (Having it support MBF21) when there is no bakery left to make the damn thing.

 

Spoiler

And Esselfortium is not the cake, just to be clear. ;)

 

PrBoom+UM does not have to support anything. I am much in favor of @dew's original request - Freeze it.

 

Heck, this may have pleasant side-effects aswell: Wad authors can now target a port much in the same way they made Boom-compatible maps but with all the additional features offered by current day PrBoom+um. Heck, as a matter of fact i believe the last two releases effectively follow this already: They are more about smaller features/bugfixes than new and innovative features.
 

5 hours ago, Gregor said:

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. ;)

GZDoom works because it is tailored towards modders first and formost. It represents one side of the sun. The featureset offered by PrBoom and consorts is the other.

 

They form the sun. They aren't in eachother way, because they occupy one side of the sun. I don't see why we need to differentiate in more than that.

3 hours ago, Kappa971 said:

why are PrBoom-plus forks created when those functions could be implemented in PrBoom-plus?

Because the vast grunt of the new features are less in spirit of the original and in the case of DSDA, it also has to target another crowd.

 

That DSDA has become as popular as it is is because it offers most of what PrBoom+um does, plus it is friendly for speedrunners, who previously relied on PrBoom+ builds. So for them its a natural development: Only the name of the game changed.

 

And i believe it will turn out the same for players too. Personal conjecture: I'd consider DSDA as its true successor.

 

1 hour 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+ 😉

If anything this recent quibble should tell, is that PrBoom+um should be put into maintenance mode: Only bugfixes when needed. So like dew said, putting it on cold ice. As it stands its a perfectly capable port and considering Entryway seemingly declared both PrBoom+um and DSDA the new ascendants to the throne, it might be best to put PrBoom+um in the Queen Mother role - Retired, but active.

 

1 hour ago, P41R47 said:

The thing is not if there are people that need it, the thing is that the option should be there because there are still lots of system out there that are 32 bits.

I disagree. Why should the option be there? Why in Joustsville is there still a need to keep supporting obsolete hardware? And this is me telling, i had a garbage computer before and even that was 64 bit!

 

I know you have a 32 bit machine, but it is actually 64 bit and its only 32 bit because the system technician did a crap job at that. And whilst there are a lot of 32 bit machines out there - How useful are they for stuff like this? So no, i don't think you should endlessly support old hardware, especially not 15 year outdated stuff. You want to play Doom on old hardware, then there are a boatload of older ports that fit the bill. *

 

* And yes, that is me being painfully aware that a lot of countries have to deal with stupendous pricing of new hardware - to the point where legacy consoles like PlayStation 2 are still considered relatively modern and a PS360, itself a legacy machine, still goes for quite a few bucks over there. I am not deaf to these argument, i am just saying: We are talking about Pentium 4/Athlon 64 levels of hardware. That's 64 bit already. That's 15 years old. At some point you have to give.

 

1 hour ago, Kappa971 said:

Then MBF21 is not a standard ;)

Laughing matters aside, but it is a standard: It is current around the ports of the other side of the sun: Woof, PrBoom, etc al

37 minutes ago, Kappa971 said:

This does not mean that past mistakes need to be repeated

And which would that be? If you really so badly want MBF21 support, try out ReBoom Experimental - PrBoom 2.02 with MBF21 and DEHEXTRA support.

Share this post


Link to post

I did not want to offend anyone, I only expressed my personal opinion, in my country (Italy) we are in a democracy. If I have offended someone, I apologize, it was not my intention but I do not understand certain arguments, perhaps it is my limit, but perhaps it is also the cause of the "fragmentation" of Doom ports functionality.
Greetings and good evening.

Share this post


Link to post

Honestly, implementing (some level of) MBF21 is something I'd like to see out of PrBoom+UM before it freezes forever. I wonder how much of an undertaking coding it and making a PR would be... I'd offer to at least start it but I'm always paranoid I'll do something considered non-standard or just flat-out wrong and just make things worse. Might be an entirely unfounded concern, IDK. Also might be an interesting way to brush up my rusty C/C++ skills...

Share this post


Link to post
1 hour ago, Redneckerz said:

I disagree. Why should the option be there? Why in Joustsville is there still a need to keep supporting obsolete hardware? And this is me telling, i had a garbage computer before and even that was 64 bit!

 

I know you have a 32 bit machine, but it is actually 64 bit and its only 32 bit because the system technician did a crap job at that. And whilst there are a lot of 32 bit machines out there - How useful are they for stuff like this? So no, i don't think you should endlessly support old hardware, especially not 15 year outdated stuff. You want to play Doom on old hardware, then there are a boatload of older ports that fit the bill. *

 

* And yes, that is me being painfully aware that a lot of countries have to deal with stupendous pricing of new hardware - to the point where legacy consoles like PlayStation 2 are still considered relatively modern and a PS360, itself a legacy machine, still goes for quite a few bucks over there. I am not deaf to these argument, i am just saying: We are talking about Pentium 4/Athlon 64 levels of hardware. That's 64 bit already. That's 15 years old. At some point you have to give.

Come on, Red!
With that reasoning, why would be other source-ports?


More options is always better!


Doom is a 28 years old game, it should run on whatever you put it on by now, and if possible, with the latest features, is that something bad?
Alright, there are other options on source-ports, like Woof! that is also MBF21 compatible, but its the same that happened before to me when i wasn't able to run GZDoom for all the heavy use of resource.
No less than a month ago i felt totally outcasted from the GZDoom codebase since my rig could't handle all the especiall and fancy looks of GZDoom, but thanks that the new GLES renderer was added, i was able to play the latest releases especially designed for GZDoom.

Having that kind of availability is something wrong or soo time consuming that nobody is able to work along with the developers to make a 32 bit official build?

And yes, at some point i will have to give, i agree with that.

And that will be when my rig gets burned or doesn't let me work and gain money with it.
Simple as that.
I don't know how carefree you can or not be with your money, but i am not in the position right now to buy a new one, especially when the prices are outrageously out of reach.
And for certain, i am not the only one in that possition.
So, its bad to ask for an option for me and the other user base that could be on a similar situation?
Especially when, since long ago, both option were always available?

Look, we have this conversation already, and the simple answer was the one that Gibbon replied: ''I don't have a 32 bit system to make it''.
Ok, that was his answer, its bad that i ask for other options out there?

Share this post


Link to post
2 minutes ago, P41R47 said:

Come on, Red!
With that reasoning, why would be other source-ports?

But there are - They are just older.

2 minutes ago, P41R47 said:


More options is always better!

If it stands in the way of flexibility, then no. I am not sure how PrBoom+ fares on insane maps in terms of memory, but if we have to be reasonable here - A Pentium 4/Athlon 64 may not cut it anyway on those extreme maps. That is usually a concurrent reason given to not use 32 bit anymore - Those machines that can only use that, will run into troubles otherwise.*

 

*I am not sure how much of that is true of PrBoom, though. GLBoom on the other end would still run happily as is - But so does DSDA-Doom which i believe inherits the GL renderer?

2 minutes ago, P41R47 said:

No less than a month ago i felt totally outcasted from the GZDoom codebase since my rig could't handle all the especiall and fancy looks of GZDoom, but thanks that the new GLES renderer was added, i was able to play the latest releases especially designed for GZDoom.

The GLES Renderer is a godsend, but its also one i can imagine won't be there forever - Its in now because all it does (roughly) is disabling the advanced post-processing attached to GZDoom as it is. Its also more mobile friendly as a result.

 

But sure, go ask 32-bit.

2 minutes ago, P41R47 said:

I don't know how carefree you can or not be with your money, but i am not in the position right now to buy a new one, especially when the prices are outrageously out of reach.

I go as long as i can on hardware - My previous rig was a 2009 Athlon X2 with Geforce 6150. Yes, that couldn't really run GZDoom - But it did run GLES.

 

Guess what: Even that stoneage machine i bought on the cheap (350 euros i believe back then) was a 64 bit processor.

 

But that's the Netherlands. I realize that in places like Brazil its far worse. But im at odds how a Pentium 4 is still worth a premium there. Mind you, we still have those too - But they are at thrift stores for a tenner.

 

Probably the irony is that what is dirt cheap here is likely the equivalent of my 2009 machine, yet it is a 2004 rig, i suppose.

 

Share this post


Link to post
3 hours ago, dew said:

Yet you namedrop @Bob9001's soon to be announced port that will reshape the world and make the others obsolete. Curious!

What?

Share this post


Link to post
4 minutes ago, Redneckerz said:

Probably the irony is that what is dirt cheap here is likely the equivalent of my 2009 machine, yet it is a 2004 rig, i suppose.

hahaha the irony is that you cheap 2009 PC is the modern ultimate high shiny model in here :P
Probably one from 2004, would be, too.

 

7 minutes ago, Redneckerz said:

I realize that in places like Brazil its far worse.

my neighbour comes from Brazil.
His rig has Windows Millenium.
He buy it new three years ago...
:/

 

9 minutes ago, Redneckerz said:

*I am not sure how much of that is true of PrBoom, though. GLBoom on the other end would still run happily as is - But so does DSDA-Doom which i believe inherits the GL renderer?

I don't have any problem playing PrBoom+ mapsets like Comatose, Remnant of Lost Civilization.
Comatose had a few slighty drop in the frame rate, but nothing important, and only while running on software.

Its cool, pal.
I know that developers can have problems with their flexibility at the time of doing their coding, but asking doesn't hurt anyone.
We understand how things are.
No worries.

Share this post


Link to post
5 hours ago, Shadow Hog said:

Honestly, implementing (some level of) MBF21 is something I'd like to see out of PrBoom+UM before it freezes forever. I wonder how much of an undertaking coding it and making a PR would be... I'd offer to at least start it but I'm always paranoid I'll do something considered non-standard or just flat-out wrong and just make things worse. Might be an entirely unfounded concern, IDK. Also might be an interesting way to brush up my rusty C/C++ skills...

Great idea! While you at it could you include a toggle button for the advanced HUD and allow it to be put on the mouse keys? That's all we need to make PrBoom+ complete.

Share this post


Link to post

I would reject any PR adding mbf21 to prboom+ personally, for all the reasons already mentioned. Of course, Fabian is ultimately the one who can decide if something should be merged. You'd need to be pretty convincing that you haven't broken a single demo in your implementation, that it's well tested, that it's complete, and that you'll be here to update it whenever the mbf21 spec is updated. Any partial implementation would be a severe blunder that's unacceptable for prboom+'s demo compatibility. Aaaand, even if you did all the work, Fabian would still need to go through the PR and check everything out to make sure it's sound - that's a significant undertaking in itself.

Share this post


Link to post

The ZDoom->GZDoom mention is apt here: while there are some small niche use cases for the former (demos, older systems, etc.), the latter is the de facto continuation of the port and the userbase as a whole has migrated to it, in large part due to new features and popular wads that require them. So shall it be with PrBoom-Plus->DSDA-Doom.

Share this post


Link to post
1 hour ago, Xaser said:

The ZDoom->GZDoom mention is apt here: while there are some small niche use cases for the former (demos, older systems, etc.), the latter is the de facto continuation of the port and the userbase as a whole has migrated to it, in large part due to new features and popular wads that require them. So shall it be with PrBoom-Plus->DSDA-Doom.

 

So let it be written, so let it be done.

Share this post


Link to post

This all sounds familiar. I remember prboom. It was 2.4.7 for awhile. I knew of prboom-plus for a good while too. I saw no reason to switch to an unfamiliar port. Eventually needed a feature prboom-plus had, so tried it out. It was not so bad. Prboom had few commits, while prboom-plus was fixing and adding a bunch of nice stuff. Some demo recording bug I found got fixed somewhere in prboom-plus, which was then backported prboom. It was only a matter of time to just move on over to prboom-plus.

 

It is hard to move away from your main port. Having an entirely different name does not help either.

Share this post


Link to post
3 hours ago, Catoptromancy said:

It is hard to move away from your main port. Having an entirely different name does not help either.

I do think the different naming will make it a bit more difficult. It feels a bit like the end of an era because of that. With ZDoom to GZDoom or PrBoom to PrBoom-Plus it didn't really feel like switching over to a new sourceport as much as simply upgrading to the newest version. Like switching from Windows 7 to Windows 10 or PS3 to PS4. But now with PrBoom-Plus to DSDA... It will feel bigger (than it actually is), just because of the name and how that messes with our psychology. I personally prefer the PrBoom-Plus name because it goes back all the way to Boom and creates that nice passing-on-of-the-torch effect. But i don't think renaming is really on the table. Who knows, maybe eventually PrBoom-plus is brought out of hibernation again or a new fork pops up that carries on the name. It could also be an advantage in a way to wipe the slate clean and start out fresh with a new name. @fabian dropped the MBF name for Woof and it didn't do it any harm as much as freeing it from any undue pressure/expectation to be more like Chocolate-MBF.

It's what it is. We'll all be fine. :)

Edited by Gregor

Share this post


Link to post

I mean, if we're all just gonna declare it dead cuz DSDA-Doom (and Woof? IDK the distinction besides "DSDA is for speedrunners primarily, Woof isn't, both are fine for casuals") does what it does but better, and people would push back against updating this even if I tried, then less work for me I guess :V

Share this post


Link to post
32 minutes ago, Shadow Hog said:

(and Woof? IDK the distinction besides "DSDA is for speedrunners primarily, Woof isn't, both are fine for casuals")

From a user perspective, the biggest difference is that Woof does not have a hardware renderer or screen resolutions above 640x400 (and the widescreen equivalent).

Share this post


Link to post

Wait..  so we've gone from demanding MBF21, 32bits, if to put it into maintenance mode and then comparisons to other source ports.

 

Talk about a derail.

Share this post


Link to post

I feel PrBoom+ was in a good path with the new demo header that added a toggleable feature-based approach to new functionality, without submitting to an unstable standard that you'd end up having to track by yet another version number.

 

In my humble opinion, if PrBoom+ is to keep adding features it would be best if they are discrete feature sets that are self-contained and stable or at least are more generic / de-hardcoded and that would be more future proof. Slowly but safely, all while making sure they wouldn't break wads that were working before. I'm not sure if MBF21 is a good candidate for that.

 

Perhaps adding MBF21 would have made more sense if it had been split in sub-features that allowed stabilicing parts of it. Also, MBF21 has already a few decisions based on making it similar to other ports (ie. the Eternity-like flags) that are kind of duplicating part of what umapinfo (and other mapinfo-like formats) already solved with more flexibility. Who knows if those MBF21 flags will become just compatibility baggage in 10+ years in the same way many flags and features in GZDoom are just there due to its legacy.

Edited by Ferk

Share this post


Link to post

This extended UMAPINFO demo header creates more problems than it helps in practice. For example, people add UMAPINFO lumps to MIDI music packs and suddenly they become demo incompatible. DSDA-Doom and Woof removed it. I think a new complevel is the right way to add new functionality.

Share this post


Link to post
12 minutes ago, rfomin said:

This extended UMAPINFO demo header creates more problems than it helps in practice. For example, people add UMAPINFO lumps to MIDI music packs and suddenly they become demo incompatible. DSDA-Doom and Woof removed it. I think a new complevel is the right way to add new functionality.

Wouldn't a complevel for UMAPINFO have the same result for a MIDI pack that adds a UMAPINFO lump and wants it to be loaded?

I don't see why using a number instead of a more extensible string would help the case.

Share this post


Link to post
4 minutes ago, Ferk said:

A complevel for UMAPINFO would have had the same result for a MIDI pack that adds a UMAPINFO lump and wants it to be loaded.

But these packs already exist, and UMAPINFO doesn't affect compatibility if it changes only music.

In other words, I think that UMAPINFO itself does not need a new complevel.

Share this post


Link to post
10 minutes ago, rfomin said:

But these packs already exist, and UMAPINFO doesn't affect compatibility if it changes only music.

 

I'm not sure I understand what you mean. Or whether I'm getting my point across.

I edited it quick to try to clarify myself but you were quicker answering.

 

"Wouldn't a complevel for UMAPINFO have the same result for a MIDI pack that adds a UMAPINFO lump and wants it to be loaded?"

 

So.. I'm talking on a situuation where a new complevel to determine UMAPINFO (which would have also been integrated in the demo header) would have been used instead of a feature flag in the new header. I feel a complevel is not really what would have solved that particular case.

Edited by Ferk

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×