PrBoom+ 2.6.66 (Jun 20, 2023)

[GratefulName]

Hmmm, i'm having some similar sound problems with Ancient Aliens, for some reason the sounds like the Wolf's Howl from Map01 doesn't seem to play for me.

I don't know why this happens as i checked inside the Wad file and the Sounds are in DOOM Format.

[Gez]

45 minutes ago, GratefulName said:

Hmmm, i'm having some similar sound problems with Ancient Aliens, for some reason the sounds like the Wolf's Howl from Map01 doesn't seem to play for me.

Now that is a scripted sound effect that only works in *ZDoom and other ACS-supporting ports (Eternity, k8vavoom, and perhaps in the future, DSDA-Doom).

[GratefulName]

22 hours ago, Gez said:

Now that is a scripted sound effect that only works in *ZDoom and other ACS-supporting ports (Eternity, k8vavoom, and perhaps in the future, DSDA-Doom).

Oh i see, funny thing is i somehow remember those sounds working for me in previous version of PrBoom+.

I Guess its just a Mandela Effect

 

[Pixel Fiend]

I don't read this thread often so I'm surprised that 320x240 in OPENGL actually displays some higher resolution, and it doesn't scale to full screen. Also seems antialiased. There's two light modes where one is too dark and one is too bright. No need to go into some explainations I guess, I just wanted to express my surprise after trying out the opengl mode.

 

I'm satisfied with what I got from PrBoom+ 261um. If I talk with someone new about Doom I'll probably recommend they download this (or Woof).

Edited October 3, 2021 by game

[JadingTsunami]

2 hours ago, game said:

Also seems antialiased.

 

There's various settings in the OpenGL menu you can try to find the look you prefer.

 

2 hours ago, game said:

There's two light modes where one is too dark and one is too bright.

 

Gamma correction is available as well (try F11/F12 keys) which may help there. If you are knowledgable about shaders you can supply your own in a WAD file which will apply light shading according to whatever algorithm you supply.

[Spectre01]

Would it be possible to implement something like GZDoom's palette tonemap as a shader for OpenGL? It's great at emulating the software look with all the benefits of hardware rendering.

 

Also, the Shaders sector light mode is the most atmospheric and accurate to the software renderer (e4m7) but the brightness diminishes too much in darker areas. It's possible to see the opposite wall in software, GLBoom, and GZDoom modes, but Shaders renders pitch black even at maximum gamma correction.

[JadingTsunami]

1 hour ago, Spectre01 said:

Would it be possible to implement something like GZDoom's palette tonemap as a shader for OpenGL? It's great at emulating the software look with all the benefits of hardware rendering.

 

If you embed the palette in your shader definition WAD, I think it should be possible. You can try it certainly. Use the "shader" light mode; this will load your custom shader if present.

[PsychEyeball]

Dumb question here, I've been tinkering with this port more and more and I'm starting to really warm up to it, but is there a reason that par times are not showing up at the end of a level? They are not showing up even though I'm just playing regular Doom 2 on it, no wads are loaded or anything.

[JadingTsunami]

1 hour ago, PsychEyeball said:

Dumb question here, I've been tinkering with this port more and more and I'm starting to really warm up to it, but is there a reason that par times are not showing up at the end of a level? They are not showing up even though I'm just playing regular Doom 2 on it, no wads are loaded or anything.

 

If you have any WAD/DEH loaded, but have not overridden par times, then the par times won't show. Are you sure you don't have any default loaded WADs or DeHackEd patches?

[PsychEyeball]

53 minutes ago, JadingTsunami said:

 

If you have any WAD/DEH loaded, but have not overridden par times, then the par times won't show. Are you sure you don't have any default loaded WADs or DeHackEd patches?

I went back to the problem and it turned out it was an issue with the in-game launcher. I somehow would load doom2.wad while having doom 2 selected as a game and that would bork the par times. It turns out you must not select any WADs at all for things to work well. My bad!

[Doncse]

On 10/4/2021 at 3:11 AM, JadingTsunami said:

 

If you embed the palette in your shader definition WAD, I think it should be possible. You can try it certainly. Use the "shader" light mode; this will load your custom shader if present.

If anybody could pull this off and be willing to share the results I would love them for it. Would do it myself but I'm too much of a vegetable for this kind of stuff. 

[printz]

PrBoom+um (on master) crashes (instead of gracefully exiting) when given malformed UMAPINFO, like this:

map MAP01
{
	levelname = "jackson
}

I'll update the post as needed.

[Never_Again]

Hi, girls! Long time no builds!

 

 

Latest Win32 dev build, as of commit 248bdc7 (September 15 2021).

 

Noteworthy changes since last official release (v2.6.1um, August 16 2021):

- added a prospective fix for OpenGL rendering: stop walls from bleeding through sky floors
- account for proper crosshair offsets when locked on to monsters
- relaxed "IWAD tag not present" error to a warning, which allows loading REKKR IWAD
- fixed processing of multiple DEHs

Bonus feature: console output that is visible without having to run prb+ from a POSIX-like terminal.

 

prboom-plus-20211018-w32.zip (Mediafire)

prboom-plus-20211018-w32.zip (FileDropper)

 

Includes the 40 required DLLs. See the accompanying TXT file for details.

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

Edited October 18, 2021 by Never_Again
color

[Gregor]

message deleted by author

Edited October 20, 2021 by Gregor

[Gregor]

Can we get a toggle key for the on-screen hud like in DSDA?

[Never_Again]

Latest Win32 dev build, as of commit 8a8a80c (October 22 2021).

 

Noteworthy changes since last dev build (October 18 2021):

* UMAPINFO: fixed error reporting if token == TK_NoToken
* fixed intermission screen for E0Mx
* fixed Alt+Tabbing on Windows, broken in new SDL2 version

+ console output

 

prboom-plus-20211022-w32.zip (Mediafire)

prboom-plus-20211022-w32.zip (FileDropper)

 

Includes the 40 required DLLs. See the accompanying TXT file for details.

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

[Never_Again]

12 hours ago, Gregor said:

Can we get a toggle key for the on-screen hud like in DSDA?

 

You mean something other than the F5 key?

[Gregor]

6 hours ago, Never_Again said:

 

You mean something other than the F5 key?

Well, i meant the single line hud that displays over the status bar which can only be turn on/off in the menu. It would be great if we could just toggle that on and off in game. The F5 key isn't for the same menu and it's not a toggle. You need a second key to bring up the status bar again and if you accidentally press F5 twice, you'll have to press it quite a few times more to bring up your preferred menu display again. And neither key can be bound to a mouse key...

Edited October 22, 2021 by Gregor

[Gregor]

Is support for options.lmp fully implemented in PrBoom-plus? When i use it with dsda or Woof it works just fine but with PrBoom-plus it has no effect, not under complevel 21 nor 11.

[GoneAway]

That lump isn't supported by prboom+.

[Gregor]

1 hour ago, kraflab said:

That lump isn't supported by prboom+.

Interesting. I assumed it would have been part of the requirements for MBF21. Good to know. Thanx!

[Shepardus]

2 hours ago, Gregor said:

Interesting. I assumed it would have been part of the requirements for MBF21. Good to know. Thanx!

PrBoom+ hasn't implemented MBF21.

Edited October 24, 2021 by Shepardus

[Gregor]

Ah. I see. Not "yet" though, right? According to the wiki it's planned at some point in the near future.

[GoneAway]

11 hours ago, Gregor said:

Interesting. I assumed it would have been part of the requirements for MBF21. Good to know. Thanx!

It's not even new in mbf21, it's supposed to be in mbf - I think woof and dsda-doom actually supported this before mbf21 :^)

[Gregor]

9 hours ago, kraflab said:

It's not even new in mbf21, it's supposed to be in mbf - I think woof and dsda-doom actually supported this before mbf21 :^)

Sounds like PrBoom-Plus has some catching up to do. ;)

[P41R47]

1 minute ago, Gregor said:

Sounds like PrBoom-Plus has some catching up to do. ;)

Aside from bug fixes, yes, there is not any major new feature added on the recent builds.

[GoneAway]

I don't think it makes much sense for prboom+ to "catch up" anymore. It serves its purpose well as a stable port covering the pure standards with lots of bells and whistles, in contrast to woof which is on the bleeding edge and somewhat more conservative and dsda-doom which is on the bleeding edge with even more bells and whistles. The trio does a great job of filling up each niche. It's not clear to me what there would be to gain from dragging prboom+ forward - it could lose its stability along the way and would also no longer fulfill the idea that "if it runs in prboom+, it runs in (mostly) everything".

[Gregor]

20 hours ago, kraflab said:

I don't think it makes much sense for prboom+ to "catch up" anymore. It's not clear to me what there would be to gain from dragging prboom+ forward - it could lose its stability along the way and would also no longer fulfill the idea that "if it runs in prboom+, it runs in (mostly) everything".

I didn't mean to suggest that PrBoom-Plus needs to follow DSDA or Woof in every feature. But i thought the whole idea of MBF21 was to push for a  "new", more advanced compatibility standard to give mapmakers more things to play with and move beyond the old Boom/MBF bottleneck across the board. But in order for that to happen, surely, PrBoom-Plus needs to implement the MBF21 standard as well.

[GoneAway]

8 hours ago, Gregor said:

But in order for that to happen, surely, PrBoom-Plus needs to implement the MBF21 standard as well.

This fork was created to show off umapinfo, and beyond that has gotten lots of support for some quality of life, bug fixing, and general polishing. But, it ultimately doesn't have a real owner (someone to decide to change what it does), more like a steward that is keeping it maintained, despite having lots of other ports to tend to at the same time. If you want to play mbf21 in a fork of prboom+, it already exists. Similarly we don't need to add mbf21 support to zdoom when it's been implemented in gzdoom. I think it's time to think of prboom+ as a "complete" time capsule and not something that needs to keep evolving.

[Gregor]

3 hours ago, kraflab said:

This fork was created to show off umapinfo, and beyond that has gotten lots of support for some quality of life, bug fixing, and general polishing. If you want to play mbf21 in a fork of prboom+, it already exists. I think it's time to think of prboom+ as a "complete" time capsule and not something that needs to keep evolving.

 

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