PrBoom+ 2.6.66 (Jun 20, 2023)

3 minutes ago, seed said:

Hence why I think a fork of a fork would be a cool idea to play with.

I guess there's nothing that stops people from developing a new fork from this fork.

1 minute ago, ChopBlock223 said:

I guess there's nothing that stops people from developing a new fork from this fork.

Certainly - except the lack of volunteers and a main developer capable of pulling that off.

Just now, seed said:

 

Certainly - except the lack of volunteers and a main developer capable of pulling that off.

Hah. If only I could help with that.

I think you guys might be interested in a couple ports called gzdoom and eternity.

11 minutes ago, kraflab said:

I think you guys might be interested in a couple ports called gzdoom and eternity.

Oh I don't think so.

15 minutes ago, kraflab said:

I think you guys might be interested in a couple ports called gzdoom and eternity.

I use GzDoom already, but the issue is that GzDoom mapping has some added complexity to it, and it seems to be way less visible to people, so though I'll gladly develop my gameplay mod project using it, I am pretty hesitant to make levels for it since few people seem to give GzDoom maps the time of day (from what I see, anyway). I'm not opposed to it, but I also want people to play my levels, and GzDoom has some of its own limitations versus Boom.

Boom format has a wider appeal for mapping, it seems, with its Rube Goldberg 'scripting' and demo compat, and I'm very comfortable mapping in the format, it has lots of great features. It does however have some bugs I wish weren't there, and the sound code leaves quite a lot to be desired. Looking at the UMAPINFO format, that's something that adds a lot of practicality to Boom ports which they never had before, without really taking it out of being a port for demo recording and oldschool gameplay. There's a lot my naive and unknowing mind imagines which could also be added to PrBoom+ or a fork of it, which, to my limited understanding, shouldn't affect things like that (though of course, work doesn't do itself).

For Eternity, I'm sorry to say that I know nothing about it, and I never see anyone ever talk about mapping for it or playing with it.

I don't want it to come across as I'm making demands or anything, by the way, so I apologize if these posts come off as needy or begging.

10 minutes ago, ChopBlock223 said:

I never see anyone ever talk about mapping for it or playing with it.

Objection.

or https://doomwiki.org/wiki/Vaporware

It's just that the port is way too overshadowed by others.

36 minutes ago, kraflab said:

I think you guys might be interested in a couple ports called gzdoom and eternity.

We are literally in a thread about stuffing a major Hexen/ZDoom feature into PrBoom, which isn't even confined to a complevel, but has a weird intertwined relationship with them.

The complexity/purity ship has sailed, IMO.

Okay, let's be honest here.

A lot of people are religiously attached to prb+ and its complevels as The Arbiter Of Truth for speedrunning and such.

(As an aside - the funny thing is that the emulations aren't quite perfect so you get e.g. "Boom compatible" maps tested in cl9 that wouldn't work in Boom.)

The word "complevel" itself kind of became this concept of "a set-in-stone set of features available that's also guaranteed to remain frame-perfect for demos from now on until forever", which is why you get requests for "cl9 but with X" and such.

PRB+'s code is also more than a little bit hard to read because of the gigantic number of "for cl2 do this, for cl4 do this, for cl11 do this" checks intertwined in the meat of it.

The risks of adding "a new complevel" are twofold - one, it increases complexity again, two, if you'll ever accidentally break a demo later you will be pitchforked and burned alive.

I think the reason of making UMAPINFO a "-1" feature was this - people still understand, I believe, that "cl -1" must be listed together with version/build of PRB+ and is not yet be guaranteed to be preserved forever.

I also kind of agree that this made it probably a lot less appealing to mappers because they got their possibility of title/exit/etc customization, but they also lost that "guaranteed logic/physics behavior" in-map.

Complevels today enforce also the flow between maps, so it makes sense they can't fully "mesh with" UMAPINFO.

But that should be solved by allowing to choose the "in-map" complevel via an UMAPINFO config entry, if this does not exist today.

So if you want to have "cl2" in-map behavior but custom level progression, sure!

Make your limit-removing map, add a secret exit in map03 and configure where it goes via UMAPINFO, and also set the game logic/physics to be "cl2-like".

As far as bigger changes go, "PRB+ but with new features" would be best to be forked under a new name.

This, importantly, would allow for a large part of the existing complevel mess to be ripped out.

I'm not saying drop the concept of guaranteed feature sets at all, of course.

For that you have gzd, k8v, and so on.

But consider that 95% of "conservative" community needs are satisfied with "Doom 2 V1.9" (cl2), "Kinda-but-not-really-Boom-2.02" (cl9) and "Kinda-but-not-really-MBF" (cl11, btw we wish it wouldn't have the MBF monster behavior included).

So I feel cleaning it up to  "featureset=vanilla" and "featureset=boom" as the two actually big ones, might be enough.

Maybe also a "boom+" to enable the "good parts of cl11" if they cannot be just permanently available in the standard boom mode.

Of course this new port would not handle 100% of the old demos due to no option to enable doom v1.0 pinky hitscan, finaldoom teleporter height issue, MBF yellow key issue and a hundred other quirks. But that's what you will have prb+ for, with the existing 17(?) complevels preserved in amber forever.

5 hours ago, Da Werecat said:

 

We are literally in a thread about stuffing a major Hexen/ZDoom feature into PrBoom, which isn't even confined to a complevel, but has a weird intertwined relationship with them.

 

The complexity/purity ship has sailed, IMO.

UMAPINFO doesn't change anything about the game mechanically - it has no effect on the behaviour of any object or any part of any map. It sits on the outer layer and has no influence on the activity inside the game engine.

People wanting new nonvanilla mechanics - make a new source port. PRBoom+ has a clear purpose of being traditional and demo compatible - if you want feature creep there are plenty of existing ports that already serve your needs, and if you want something in between then you need a new port.

So in this case, who's up for a new port :p ?

I guess I'm curious as someone who only interacts with prb+ as a demo player, what is it about prb+ in particular that you want to add demo destructive features (as in, not just like, sound and graphics renderer changes) to it instead of using a different port that already fills those needs

2 hours ago, siteod said:

I guess I'm curious as someone who only interacts with prb+ as a demo player, what is it about prb+ in particular that you want to add demo destructive features (as in, not just like, sound and graphics renderer changes) to it instead of using a different port that already fills those needs

I think prboom+ is faster than most ports. And it has that nice viddump feature. So maybe someone wants to use it on an older PC or to permanently record demos which they will later convert to video, if the demos end up successful/interesting. But maybe they want the infinitely tall actors disabled for better gameplay.

Anyway, I don't personally care about prboom+ too much, I just threw an idea out there. There was a time I used it to play BTSX E1 some years ago, at some point I couldn't drop down a ledge because of some demons below. I went back RUNNING to GZDoom and Doom Retro as soon as I finished that episode. It also had an annoying bug where if you alt-tabbed then the next time you pressed Enter it counted as an alt-enter and switched to windowed mode lmao OK.

4 hours ago, kraflab said:

UMAPINFO doesn't change anything about the game mechanically - it has no effect on the behaviour of any object or any part of any map. It sits on the outer layer and has no influence on the activity inside the game engine.

It's an important outer layer. I'm not entirely convinced the distinction is this clear. There must be a reason that a discussion of DEHACKED extensions flowed so naturally from this, and those definitely have an effect on what's happening within maps.

To be clear, I've been conflicted about all of these half-measures (including UMAPINFO) for quite some time. I do not have a clear vision of what the end result should look like. As a sorta-mapper who enjoys the idea of limitations as a challenge to overcome, it's infuriating when a supposedly-elegant setup doesn't fall into place due to some stupid bug or unforeseen quirk, but on the other hand amending it in a modern fork feels like cheating.

56 minutes ago, Da Werecat said:

It's an important outer layer. I'm not entirely convinced the distinction is this clear. There must be a reason that a discussion of DEHACKED extensions flowed so naturally from this, and those definitely have an effect on what's happening within maps.

Being able to add your own frames and things to DeHacked doesn't seem like it would affect demo compat or anything, the things you do would still have to be things that are possible with DeHacked as is, ergo it would use existing properties and the PRNG table.

Am I correct in this?

5 hours ago, seed said:

So in this case, who's up for a new port :p ?

I would encourage it for anyone who wants to try.

I would however also still be more than willing to settle for just UMAPINFO, extended DeHacked, and bugfixes, that would still be fantastic to me as is.

Unless we're talking about new codepointers. But those shouldn't make too much of a mess from the programming standpoint. Which, I'm guessing, all of this boils down to.

.

16 hours ago, Krull said:

https://doomwiki.org/wiki/DEHEXTRA

Yes, that was the one I was thinking of. I think that would be an extremely useful addition, and if I understand correctly, it shouldn't require any sacrifices of compatibility with demos.

41 minutes ago, ChopBlock223 said:

Yes, that was the one I was thinking of. I think that would be an extremely useful addition, and if I understand correctly, it shouldn't require any sacrifices of compatibility with demos.

It's already in the fork. 

4 hours ago, fabian said:

It's already in the fork. 

Pardon my poor attention span.

How does DEHEXTRA compare to what's available with MBF? Can something like Valiant or Eviternity be made in Boom using it, with the same amount of modified and custom content?

35 minutes ago, Spectre01 said:

How does DEHEXTRA compare to what's available with MBF? Can something like Valiant or Eviternity be made in Boom using it, with the same amount of modified and custom content?

It basically builds upon it. It won't give you the extra codepointers from MBF (Spawn, Scratch, RandomJump, etc.) if you don't already have them, but you do get a lot of new frames to play around and new things you can modify, so it gives you a lot of room to add custom content without having to sacrifice any vanilla content for it.

I don't really get those consistency checks. Are they supposed to prevent demo/network desyncs? They feel like a nuclear option, even at times crashing the game. They also are kind of clumsy to deal with, like in my fork where I tried to write some bots, often they would die and crash the game. Yes, I did use -solonet.

Someone who has had more experience with the Doom source tree than me would probably do a better job than me at this kind of stuff. Gustavo6046/prboom-plus, branch gus-experimental.

I know, my question sounds a bit vague, and it's probably out of the scope of Mr. Oelckers' PRBoom+ fork anyway. I should probably move it elsewhere -- but where? Perhaps a new thread?

And really I'm mostly just having wierd issues with crashing in my fork. Often not segfaults, but what I assume are sanity check errors, dispersed across the core of the source code (like the Ticker functions that call underlying subroutines).

Latest Win32 dev build, as of commit 414e0e4 (Dec 30 2020), plus two extras.

Noteworthy changes since my last dev build (June 26 2020):

* added automap rotate and overlay keybindings to menus
* added "Dropped Item" menu support
* added 200 Sounds for DEHEXTRA
* respawn when using IDDQD while dead
* restrict "next level" button usage to in-level only
* added adaptations for fluidsynth 2.0
* added "No Vertical Mouse" setting and keybind
* save / load -complevel 9 friction
* added extensible demo format + "PR+UM" signature
* fixed wrong aspect ratio for resolutions 320x200 and 640x400 (official commit pending)
* own fix for the "Garbage lines at the top of weapon sprites" issue

prbboom-plus-20210106-w32.zip

For a complete list of changes since last official release look here.

Xtra heavy kudos to @fabian for the 320x200 AR fix.

2 hours ago, Never_Again said:

Xtra heavy kudos to @fabian for the 320x200 AR fix.

Thanks!

> * own fix for the "Garbage lines at the top of weapon sprites" issue

What exactly is the code change behind this?

No code changes there; the fix for the "Garbage lines at the top of weapon sprites" issue is three modified sprites for the chaingun and the plasma rifle in prboom-plus.wad.

Latest Win32 dev build, as of commit 24e10c7 (Jan 7 2021) plus an unofficial extra.

I know, I know, another build in less than 24 hours, but hey - look at the changelog!

Noteworthy changes since last dev build (Jan 6 2021):

* made canonical resolutions (320x200, 320x240, 640x400 and 640x480) 
  always available in menu, regardless of what video driver/SDL report
* fixed aspect ratio for canonical resolutions; be sure to set "Aspect Ratio" to "Auto"
  and "Status Bar and Menu Appearance" to "Not Adjusted" for both 320x200 and 640x400
* set minimum windows size to prevent window from shrinking when changing video modes

prboom-plus-20210107-w32.zip

See the accompanying TXT file for details.

For a complete list of changes since last official release look here.

I think at this point it would be no slight to all the other contributors to call this fork @fabian's fork.

What's with the mouse sensitivity? It's set to 10 and suddenly extremely slow.

I tried to build Prboom on MSYS2 but cmake cannot find the libraries and include directories. I tried again on the gui CMake and pathed them, but it still couldn't build properly.