PrBoom+ 2.6.66 (Jun 20, 2023)

[ChopBlock223]

How's progress going on this overall, if it's ok to ask? Did you ever settle on a name?

[seed]

3 minutes ago, ChopBlock223 said:

How's progress going on this overall, if it's ok to ask? Did you ever settle on a name?

 

The port is very much alive, but no name changes for the time being.

 

Also Graf is not maintaining it actively currently, and hasn't for months.

[VGA]

Obviously name it "prboom-minus" ...

 

Will it ever have an option to toggle infinitely tall actors by the way? 

[seed]

8 minutes ago, VGA said:

Obviously name it "prboom-minus" ...

 

Will it ever have an option to toggle infinitely tall actors by the way? 

 

I doubt it, such a feature is pretty much antithetical to PrBoom's philosophy as a port.

[Da Werecat]

I know what the objections will be: breaking too many maps, etc. But there's a way to avoid that by making it more like "infinitely tall monsters". Everything that doesn't have action frames should remain infinitely tall for all the situations where decorations are used in place of walls.

[Spectre01]

Doesn't Crispy Doom have the option to disable infinite height, despite being a popular authentic port used for demo recording?

[T.Will]

2 hours ago, Spectre01 said:

Doesn't Crispy Doom have the option to disable infinite height, despite being a popular authentic port used for demo recording?

It does. But just because Crispy offers it doesn't mean PrBoom will or even should.

[fabian]

12 hours ago, T.Will said:

It does. But just because Crispy offers it doesn't mean PrBoom will or even should.

I am not generally opposed to adding a feature like this to PrBoom+. I mean, we even have jumping and stuff, though restricted to non-demo-critical play. One thing to sort out early would be if the actual size in sprite pixels is to be used or the `height` value of the corresponding mobj_t object. 

[ChopBlock223]

Would the option for not having those infinite height limitations mean adding a new complevel, or would it straight up be assumed that it means you're not having demo compat if you use it?

 

For height, monsters and other objects do have defined heights already, right?

[ketmar]

5 minutes ago, ChopBlock223 said:

For height, monsters and other objects do have defined heights already, right?

monsters -- yes. but most decorations in vanilla has dummy 16 units height. id never bothered to set it right, because you cannot walk over decorations. this is also why projectiles pass through decorations: actually, decorations do stop projectiles, but being only 16 units high it's hard to catch something that is usually flys much higher. ;-)

[fabian]

8 minutes ago, ChopBlock223 said:

Would the option for not having those infinite height limitations mean adding a new complevel, or would it straight up be assumed that it means you're not having demo compat if you use it?

 

The second. No more complevels at this point. 

 

8 minutes ago, ChopBlock223 said:

For height, monsters and other objects do have defined heights already, right?

 

These values often do not match the monster's actual sprite height in pixels. 

[ChopBlock223]

The height of the sprite itself seems not too relevant, given that Revenants aren't as tall as they look and even in some iwad maps that's apparent.

I assume there's complication with adding new complevels, but what are those? I hope I'm not being bothersome with these questions.

[Gez]

It was found simpler to just make these non-conservative options and demo recording mutually exclusive; that way no need to create new complevels!

[ChopBlock223]

I guess so, though what about bugs like generalized walkover crusher linedefs not working? Will that be something that will be fixed, and will that affect complevels at all?

[Da Werecat]

So if a map is made with finite heights in mind, it's not demo-compatible? Not much point in this feature then.

 

Somehow this solution feels like making even more of a mess.

 

[fabian]

41 minutes ago, Da Werecat said:

So if a map is made with finite heights in mind, it's not demo-compatible? Not much point in this feature then.

Sorry, wrong engine then - or maybe even wrong game? This is not just a bug fix. Just like jumping, this us an entirely Doom incompatible change that needs to get hacked into the engine. It doesn't make sense to define a "compatibility level" for it. 

[Da Werecat]

I will reiterate my question then: what's the point of adding it at all?

 

Chocorenderlimits has rudimentary jumping, but it has a purpose of simulating arch-vile attacks for testing.

[fabian]

For the occasional just-for-fun playing, I guess. At least that's the reason why I added it to Crispy. ;-)

[Da Werecat]

Then I think the idea of separating by the presence of action states should be useful, to prevent sequence-breaking or getting stuck, or at least minimize the possibility.

 

Unless that's how it works already, I haven't used Crispy much.

[JadingTsunami]

As I understand it (and I'm of course open to correction on this), at this point, PrBoom is feature complete in terms of demo recordable gameplay.

 

Bug fixes that don't break demo compatibility and "quality of life" enhancements are on the table, but most everything else is closed for modification under the PrBoom banner.

 

A new port would be a possible path to further extension, but it's hard to see what niche it would fit into at this point given the other ports that are available.

[Spectre01]

As far as features go, what I want to see most is an updated sound system where you don't have to choose between sound cutoff or getting your eardrums obliterated by monsters waking up. I believe Graf talked about implementing GZDoom's 128+ channel system before as an idea. After that, and alternative HUD with the option to show ammo numbers would be great. I haven't used the default status bar in years; at this point, all it does for me is restrict vertical line of sight. And finally, -longtics for complevels 9/11 as implemented in this fork. I am somewhat perplexed at the resistance to have normal mouse input while demo recording, especially when it's already implemented for vanilla formats. Yes, those won't play in every other Boom port, but what is the issue if the option exists in the main updated version moving forward?

[Da Werecat]

This whole fork is weird to begin with. Not unwelcome, but weird.

[seed]

Agreed, and for a fork there's still way too much resistance to adding new features.

 

In fact, in terms of features it seems to be locked in place as well, which sounds like a complete waste to me.

 

At this point I'd rather have someone else fork it, someone who is not afraid of breaking the convention and status quo.

[ChopBlock223]

I had looked at a bunch of older discussion in the past, and the impression I got was that there were talks about adding things like an extended DeHacked format to let you define and use your own frames. I imagine that as long as it all still adheres to the PRNG, that shouldn't be the most bothersome thing to add and shouldn't even require any changes to compat levels, however it seems that some suggested bugfixes may just require a new compat level (after all, if the bug is present in an existing demo, couldn't that cause a desync if the bug was fixed?), hence why I wonder why there seems to be a resistance to defining a new complevel.

 

I really know nearly nothing about coding, so excuse me for my ignorance, but I'm also really interested in learning answers to questions like these.

[seed]

8 minutes ago, ChopBlock223 said:

I wonder why there seems to be a resistance to defining a new complevel.

 

That's primarily because the levels are pretty much locked in place after so much time, as a result there is less incentive to change or add something else.

 

But if some of these changes require a new complevel or more, I am more than fine with it. Though instead of that, we may just see nothing instead.

[ChopBlock223]

Locked in place? Would adding a new complevel require altering the old ones somehow?

[seed]

47 minutes ago, ChopBlock223 said:

Locked in place? Would adding a new complevel require altering the old ones somehow?

 

No, by that I meant that the complevels as a whole and the way they work is mostly locked in place because they are considered "complete", so any change here is very unlikely, be that modifying and existing level or adding another.

[Spectre01]

1 hour ago, seed said:

That's primarily because the levels are pretty much locked in place after so much time, as a result there is less incentive to change or add something else.

Could that not be said about the sound system, GL renderer, or any other aspect of the port which could use an update? Plus there are what, 17 complevels, out of which 2, 3, 4, 9, 11, and -1 get any use. 11 functionally sucks with infighting behaviour and is only used because it allows more dehacked modification. And -1 gets used because people want to save and load while recording FDA's or use -longtics for Boom+ stuff, but is incompatible between versions. I don't see why somebody would get upset if a few new complevels were added which let you play MBF format without the janky mechanics or -longtics. There is also the speedrunning fork and the stable 2.5.1.4/5 releases aren't going anywhere. 

[fabian]

Guys, the fork's primary purpose was to add UMAPINFO support to PrBoom+. This goal may be considered complete except for some minor changes required for the demo format pull request. 

 

Since e6y, the author of the original PrBoom+ has completely vanished off the scene, we have taken the opportunity to use this fork for some code maintenance and bug fixes - and to add some minor features requested by the modding and speed running communities. Nothing big. 

 

Nobody has ever promised to turn PrBoom+ into a feature port. It is still the most conservative source port next to Chocolate Doom, so please adjust your expectations. 

[seed]

9 minutes ago, Spectre01 said:

Could that not be said about the sound system, GL renderer, or any other aspect of the port which could use an update? Plus there are what, 17 complevels, out of which 2, 3, 4, 9, 11, and -1 get any use. 11 functionally sucks with infighting behaviour and is only used because it allows more dehacked modification. And -1 gets used because people want to save and load while recording FDA's or use -longtics for Boom+ stuff, but is incompatible between versions. I don't see why somebody would get upset if a few new complevels were added which let you play MBF format without the janky mechanics or -longtics. There is also the speedrunning fork and the stable 2.5.1.4/5 releases aren't going anywhere. 

 

Oh it sadly definitely could, I would honestly love if it got a new render or have it promoted to GL 3.3 instead, have its bugs sorted out, and of course, get a better sound system, but since none of these have happened for such a long time, I don't honestly think they will ever come to fruition.

 

Also the sound system replacement is in limbo. Graf is busy with other projects nowadays and the likelihood of it ever getting replaced with OpenAL or something else are slim.

 

8 minutes ago, fabian said:

Nobody has ever promised to turn PrBoom+ into a feature port. It is still the most conservative source port next to Chocolate Doom, so please adjust your expectations. 

 

Of course, but I would sure like to see that happen honestly. Hence why I think a fork of a fork would be a cool idea to play with. I would be the first in line to do that if I could.