PrBoom+ 2.6.66 (Jun 20, 2023)

... and getting around that is really out of scope for a demo compatible port. Eternity had to introduce a completely separate code path to allow height aware collision detection while not sacrificing demo compatibility.

Hypothetically speaking, how difficult would it be to implement a new demo format, similar to GZDoom's Default preset, with all the vanilla bugs fixed?

Edit: On a related note, -longtics support for -complevel 9 from this fork by @cybermind would also be pretty cool. As would an option to limit framerate to something like the 200 cap GZDoom has. I've seen GLBoom+ approach 2k FPS on simple maps, which distorts the image quite a bit when making quick turns (and allegedly bad for your GPU). I've been using RivaTuner to cap FPS at 200, but that was actually the culprit causing my screenshot crashes.

1 hour ago, Spectre01 said:

Hypothetically speaking, how difficult would it be to implement a new demo format, similar to GZDoom's Default preset, with all the vanilla bugs fixed?

almost impossible. the moment somebody will try to do that, there will be huge s...torm ;-) about "waaargh, they broke our precious demos!" it doesn't matter if it will be optional, and opt-in, the worms will be out of the can, and nobody will be able to get 'em back. i am pretty sure that nobody wants to stand against all that bashing for such a small thing.

You do not need a new demo format but a new engine. Even ZDoom never changed the basics of what demos contain, it merely extended it to handle the newer engine features by providing optional records.

I will admit I see the appeal of having a mostly-vanilla experience that just happens to let you jump on enemies' heads, given vanilla Hexen and vanilla Strife both had that, but I'm inclined to agree that given PrBoom+'s heavy focus on demo compatibility, it's not worth the hassle at present, if ever.

10 minutes ago, Shadow Hog said:

I will admit I see the appeal of having a mostly-vanilla experience that just happens to let you jump on enemies' heads.

Crispy Doom does provide this, mind.

Clearly the solution here would be to abandon prboom alltogether and just focus on making a crispy boom

2 hours ago, Spectre01 said:

Edit: On a related note, -longtics support for -complevel 9 from this fork by @cybermind would also be pretty cool. As would an option to limit framerate to something like the 200 cap GZDoom has. I've seen GLBoom+ approach 2k FPS on simple maps, which distorts the image quite a bit when making quick turns (and allegedly bad for your GPU). I've been using RivaTuner to cap FPS at 200, but that was actually the culprit causing my screenshot crashes.

I would like to see these features too. Especially the fps cap feature.

If someone has an objection to full -longtics support on the grounds that you can't do that in stock Boom, then could someone maybe hack the feature into the Boom executable a la Doom+? Then it would be ultra justified.

I'm way past recording FDAs, but at the time my main deterrent was vomit-inducing controls in Boom maps (and above).

FPS cap and -longtics support for -complevel 9 and 11 are something I'd definitely be interested in, but I recall the latter opened a can of worms and it could allegedly cause some incompatibilities/need a new -complevel just for it?

But the cap is definitely good, especially if the VSync issues cannot be remedied, which I really hope is not the case. Until then, I've learned to get used to capped framerate in PrBoom though.

2 hours ago, Da Werecat said:

If someone has an objection to full -longtics support on the grounds that you can't do that in stock Boom, then could someone maybe hack the feature into the Boom executable a la Doom+? Then it would be ultra justified.

 

I'm way past recording FDAs, but at the time my main deterrent was vomit-inducing controls in Boom maps (and above).

Slightly related, but stock Doom2.exe has had a longtics patch, as 1.91.

This can be used on top of Entryway's DoomP/Doom2P limit raising executables.

11 hours ago, seed said:

FPS cap and -longtics support for -complevel 9 and 11 are something I'd definitely be interested in, but I recall the latter opened a can of worms and it could allegedly cause some incompatibilities/need a new -complevel just for it?

Currently, @cybermind's fork uses the same complevel for -longtics recordings, they are just incompatible with versions of PRBoom+ that don't have that support. i.e. You can't watch those in regular 2.5.1.4/5. But if 2.5.1.7+ is the version going forward, you could simply upgrade from the dead/feature complete builds to watch them. I'm no hardcore speedrunner, so the current compromise is just using cl-1 for cl9/11 stuff if I feel like recording something. Also, possible hot take, but cl11 just kind of sucks anyway with how it butchers infighting AI. I play those wads in GZDoom or cl-1 so that they feel like cl9. The benefit of 11 is more freedom when it comes to dehacked changes, but the other aspects can suck a lemon.

1 hour ago, Spectre01 said:

The benefit of 11 is more freedom when it comes to dehacked changes, but the other aspects can suck a lemon.

Like lighting transfer line actions. Except they're just as crappy in cl-1, IIRC.

5 hours ago, Spectre01 said:

Currently, @cybermind's fork uses the same complevel for -longtics recordings, they are just incompatible with versions of PRBoom+ that don't have that support. i.e. You can't watch those in regular 2.5.1.4/5. But if 2.5.1.7+ is the version going forward, you could simply upgrade from the dead/feature complete builds to watch them. I'm no hardcore speedrunner, so the current compromise is just using cl-1 for cl9/11 stuff if I feel like recording something. Also, possible hot take, but cl11 just kind of sucks anyway with how it butchers infighting AI. I play those wads in GZDoom or cl-1 so that they feel like cl9. The benefit of 11 is more freedom when it comes to dehacked changes, but the other aspects can suck a lemon.

Hm, yeah, that seems to be what I remembered too.

But how dare ya force people to upgrade to new versions!!!!!

1 hour ago, Voltcom said:

Just wondering, will this port ever be hosted on https://devbuilds.drdteam.org/ at any point in the future?

If a daily build system is ever made, like the other ports have, most certainly. I think it's pretty much the only reason why it currently isn't.

But until then, there isn't any point in doing that. And, I'll keep providing builds for Windows when new changes are made to keep people up-to-date :) .

@Graf Zahl Sorry to ping you here, but I didn't get any replies from you on Github. Could you please have a look at the three pending pull requests that we have for prboom-plus and either post your thumbs up or down? I know I could merge them myself but would like to hear your final word about them.

I'm currently working on a universal wad for Ultimate Doom with Dehacked, Dmapinfo, Emapinfo, Zmapinfo, and mapinfo, UPDATE: added Umapinfo,

in that order.

Gotta collect 'em all!

Sporadically replacing maps here and there and adding some:

Anything in episodes 1-4 except secret missions after 9 is playable in doom.exe.

Dmapinfo enables E1M10, E2M10, and E2M11 for Doom Classic 2019, as does any other ports' mapinfo.

Mapinfo has a couple Episode 5 Hexen format versions of maps for Odamex/ZDaemon.

Emapinfo has a couple E6 UDMF versions for Eternity.

Zmapinfo has four E7 UDMF maps for Zandronum/LZDoom/GZDoom/*ZDoom and also sets up the E5 Hexen format maps for them.

I know with Zmapinfo present, those ZDooms won't even parse the older format Mapinfo.

So if I add a Umapinfo for PrBoom, will that mess up GZDoom reading ZMapinfo?   And obviously I don't want PrBoom to try to load map formats it doesn't support.   Which map formats does PrBoom support anyway, just Doom format with Boom/MBF + additional features, right?   Anyway, the dehacked for name changes is there.   It will just miss out on two maps Doom Classic 2019 can access.  But one of those is some goofy old thing to fill a secret exit slot and another old thing was designed for deathmatch, so it's really not missing much.   The replacement E2M9 is a duplicate of E1M10 so no version of Doom misses out on that map.

The actual FINISHED wad in question, unless I find something while testing, add that Umapinfo, get another crazy idea, or until I give it a more standard txt file.  Works right out of the box with doom.exe but dehacked(stuff commented out) or patchdeh(less stuff commented out) are there if you want to apply it (neither messes up the replacement demos for doom.exe/Eternity/Odamex).   E4M1's main feature requires it but you can still play and pass through the map without it.

EDIT: Added Umapinfo aside from ZD&EE tweaks.

EDIT EDIT: changed link to finished wad.

I'm pretty sure, from prior experimentation, that GZDoom will read ZMAPINFO over UMAPINFO if it's present, so you don't really need to worry about that.

Typically, GNU/Linux software does not get packaged; rather, a build system like CMake or GNU Autotools is used to assist with the compilation, and the distributions (e.g. Debian, Arch Linux, etc) are responsible for packaging and distributing it (if they include the software in their repositories), or making sure that the user can compile any software they want to with the toolsets usually available.

Yes, this means that, as average Linux users, we compile C code far more often than the average Windows user. On the other hand, it's a lot less painful. But that's already beside the point.

In the meantime, I have decided that it might be a good time for another release, so here you go, I present you the May 15th build.

A list of changes can be found in the spoiler below and in the included text file, along with more information. Now it also comes in both 64-bit as well as 32-bit flavor, for those who are still stuck with 32-bit operating systems or simply prefer to use such a version for one reason or another.

https://drive.google.com/file/d/13NtuaNDokaVxvmHVz1qbaNdA87GXHXy3/view?usp=sharing

Report any issues you find & have fun!

Finally I can play without problems on my computer with this version, thanks!

13 hours ago, seed said:

In the meantime, I have decided that it might be a good time for another release, so here you go, I present you the May 15th build.

 

A list of changes can be found in the spoiler below and in the included text file, along with more information. Now it also comes in both 64-bit as well as 32-bit flavor, for those who are still stuck with 32-bit operating systems or simply prefer to use such a version for one reason or another.

 

  Reveal hidden contents

• Fixed compilation when CMAKE_FLAGS_C is set.
• Fixed endianess for 32-bit ZDoom nodes (Michael Bäuerle).
• Show the extended help screen when pressing the "Help" key.
• HUD armor color now depends on type instead of amount.
• Added Chocolate Doom mouse behavior option.
• Fixed Boom auto-switch behavior.
• Fixed building with GCC 10.1.
• Added back the "Weapon Attack Alignment" menu option, which disappeared by accident at some point.
• "Secret Areas" menu option has been renamed into "Report Revealed Secrets".
• Clear sound buffer when updating, to avoid potential noise.

 

https://drive.google.com/file/d/13NtuaNDokaVxvmHVz1qbaNdA87GXHXy3/view?usp=sharing

 

Report any issues you find & have fun!

Thank you for this build! However i'm having micro stuttering with this version, both 32 and 64 bits, and both GL and software mode(8-bit), while with 2.5.1.7 i was not, it was super smooth.

The mouse control feels to me like it's always emulating demo short tics, even when I'm not recording one. Turning on "Carry Fractional Tics" helps, but it's still lacking in very fine precision.

On 5/16/2020 at 2:37 AM, Demion said:

Thank you for this build! However i'm having micro stuttering with this version, both 32 and 64 bits, and both GL and software mode(8-bit), while with 2.5.1.7 i was not, it was super smooth.

Hm, can't say I've never experienced something similar in the past. I would occasionally have microstutters in 2.5.1.5 but they were completely random, coming and going by themselves. Never figured out why that was.

11 minutes ago, Bashe said:

The mouse control feels to me like it's always emulating demo short tics, even when I'm not recording one. Turning on "Carry Fractional Tics" helps, but it's still lacking in very fine precision.

That's odd. It works just fine for me, and no-one else has reported similar issues so far.

Also, @fabian, I've noticed that you recently reverted the buffer fix commit. Did it cause unexpected issues?

I'm having that issue of mouse control emulating demo short tics even without recording, as well.

46 minutes ago, Bashe said:

The mouse control feels to me like it's always emulating demo short tics, even when I'm not recording one.

14 minutes ago, StoneMason said:

I'm having that issue of mouse control emulating demo short tics even without recording, as well.

I haven't updated to the latest version yet but nobody deserves to be subjected to -shorttics torture.

33 minutes ago, seed said:

Also, @fabian, I've noticed that you recently reverted the buffer fix commit. Did it cause unexpected issues?

Yes, it killed SDL music on Linux.

1 hour ago, seed said:

That's odd. It works just fine for me, and no-one else has reported similar issues so far.

1 hour ago, StoneMason said:

I'm having that issue of mouse control emulating demo short tics even without recording, as well.

Alright, actually I do take that back, apparently my DPI was set higher than it usually is - and I thought I was just imagining things in Windows...

It does indeed seem to be -shorttics behavior by default now, but enabling fractional tics seems to fix it more or less, while still not being quite the same. Peculiar, I wonder what changed the default behavior, since the last version the only notable input change was the addition of Chocolate Doom mouse behavior. Maybe something changed there which decreased mouse resolution? -longtics seems to do nothing as well.

47 minutes ago, fabian said:

Yes, it killed SDL music on Linux.

Whoops, that's unexpected. But since I don't use Linux I had no way of knowing.

It looks like a new version might be on the way as well, I noticed the CVE this morning. That alone warrants a new one.

Latest Win32 dev build, as of commit 3473516 (June 6 2020)

Noteworthy changes since seed's last build (May 15):

* fixed endianess for DeePBSP V4 nodes
* show error message boxes on Windows, except when video-dumping a demo
* unbind game speed changing keys in default config
* fixed heap buffer overflows in UDP multiplayer code
* fixed -longtics having no effect

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

If you get an error complaining about a missing DLL read the instructions at the end of the accompanying TXT file.

prbboom-plus-20200606-w32.zip

On 6/8/2020 at 5:05 AM, Never_Again said:

* fixed -longtics having no effect

Does it concern -complevel 9 issue?

Thank you for compiling it!

43 minutes ago, Dimon12321 said:

Does it concern -complevel 9 issue?

Thank you for compiling it!

No, it concerns an oversight regarding the Chocolate-like mouse behavior/fractional tics, which caused the game to run in -shorttics mode by default and the -longtics parameter to be ignored.

-longtics only works for vanilla/limit-removing complevels, not Boom/MBF.