PrBoom+ 2.6.66 (Jun 20, 2023)

[rfomin]

1 hour ago, nobleflame said:

This version seems to completely break fluidsynth for me. Some notes are completely missing or only play for a brief second before cutting out. 

As far as I remember, there were no changes in Fluidsynth in this version. I suspect it was unable to find the soundfont and fall back to OPL2.

[nobleflame]

52 minutes ago, rfomin said:

As far as I remember, there were no changes in Fluidsynth in this version. I suspect it was unable to find the soundfont and fall back to OPL2.

 

I made sure that the sound font was located in the prboom folder and edited the config accordingly. 

 

When going back to the previous build, it appears to have fixed it. Not sure what the issue is, but something's messing with fluidsynth.

[ceski]

4 hours ago, nobleflame said:

This version seems to completely break fluidsynth for me. Some notes are completely missing or only play for a brief second before cutting out. 

 

Try this: prboom-plus-20221204-win64.zip

 

Please share the name of the wad you were using.

Edited December 4, 2022 by ceski

[Never_Again]

I tested ceski's Dec 2 build in a new folder with all default settings and TimGM6mb.sf2. Fluidsynth is the default MIDI player. Sounds the same as my own 32-bit dev build, which in turn sounds the same as the official release from February.

 

Must be a config issue and/or a DLL mismatch. Process Hacker can tell you prboom-plus' Current (i.e. Working) Directory while prb+ is running, and on the Modules tab of the exec's Properties the location and version of libfluidsynth-3.dll it's using.

[nobleflame]

13 hours ago, ceski said:

 

Try this: prboom-plus-20221204-win64.zip

 

Please share the name of the wad you were using.

Cool, thanks, mate. I'll try this later. 

 

I was using Sunlust, but all wads I tried were also affected. DOOM II also sounded weird. 

[nobleflame]

18 hours ago, ceski said:

 

Try this: prboom-plus-20221204-win64.zip

 

Please share the name of the wad you were using.

 

This new version seems to have sorted out all of the issues I was having. I made no changes to my config file and deleted all old .dlls before dropping the contents of the zip into my prboom folder.

Not sure what happened there, but it worked. Cheers.

[lastplayer]

Will prboom+ continue to be updated? 

[emailking1]

On 12/4/2022 at 5:10 PM, ceski said:

 

Try this: prboom-plus-20221204-win64.zip

 

Please share the name of the wad you were using.

 

Is there a glboom plus version of this?

[Shepardus]

21 minutes ago, emailking1 said:

 

Is there a glboom plus version of this?

They're the same thing, just choose the OpenGL renderer in the options.

 

On 12/6/2022 at 2:07 PM, lastplayer said:

Will prboom+ continue to be updated? 

It's in maintenance, so there may be bugfixes but don't expect any significant feature development. If you want that, check out dsda-doom.

[emailking1]

16 minutes ago, Shepardus said:

They're the same thing, just choose the OpenGL renderer in the options.

 

Ok I guess he just separated them before. I figured that out now. 

 

But it keeps kicking me out unless I leave the resolution on the default 640x480. Like if I put the resolution to 1920x1080 which is what my screen is, windows just kicks it back to the desktop and proboom-plus keeps running the the background (I can hear it running, monsters and everything). If I click the the prboom-plus window it tries to bring me back but then just kicks me out again. And I can only close prboom-plus by killing it in task manager since it won't stay up for me to exit with Escape -> Y

 

I tried updating for the first time in 5 years because the same thing just started happening to me on my old version. I figured maybe it was an incompatibility with a windows update that happened sometime this year (I forget when I last launched it before this). But apparently not since this new version does the same thing and no one else seems to have the problem. Any ideas?

Edited December 11, 2022 by emailking1

[nickxcom]

Maybe a stupid question, but what exactly is "prboom-plus.wad"? Do I need to add it to my load order in ZDL or is it picked up automatically? I see many similar wads or PK3s for my various source ports, but I have literally never added these to my ZDL order. SHOULD I be? What exactly does this wad or similar wads DO? I can't find much on google.

Edited December 12, 2022 by nickxcom

[Shepardus]

46 minutes ago, nickxcom said:

Maybe a stupid question, but what exactly is "prboom-plus.wad"? Do I need to add it to my load order in ZDL or is it picked up automatically? I see many similar wads or PK3s for my various source ports, but I have literally never added these to my ZDL order. SHOULD I be? What exactly does this wad or similar wads DO? I can't find much on google.

It's automatically loaded. The best way to understand what it contains is to just open it up in SLADE and see what's inside. In the case of prboom-plus.wad, it contains color translation tables, the graphics and sounds for dogs, graphics for HUD/menu elements that aren't part of the vanilla game, the DeHackEd patch for playing Chex Quest, and some other miscellaneous things of the sort.

[fabian]

PrBoom+ wouldn't even start of it couldn't find its prboom-plus.wad file. 

[nickxcom]

On 12/11/2022 at 9:47 PM, Shepardus said:

It's automatically loaded. The best way to understand what it contains is to just open it up in SLADE and see what's inside. In the case of prboom-plus.wad, it contains color translation tables, the graphics and sounds for dogs, graphics for HUD/menu elements that aren't part of the vanilla game, the DeHackEd patch for playing Chex Quest, and some other miscellaneous things of the sort.

 

On 12/12/2022 at 1:15 AM, fabian said:

PrBoom+ wouldn't even start of it couldn't find its prboom-plus.wad file. 

Thank you both! It was just one of those "Huh... I know I've seen this before, but I literally have no idea what these do" kind of things :)

[Never_Again]

On 12/11/2022 at 2:17 AM, emailking1 said:

it keeps kicking me out unless I leave the resolution on the default 640x480. Like if I put the resolution to 1920x1080 which is what my screen is, windows just kicks it back to the desktop and proboom-plus keeps running the the background (I can hear it running, monsters and everything).

 

If your issue is something like this you may want try the Mesa3D solution in that thread.

[NightFright]

Can anyone provide latest working Win x64 build? For some reason, the binaries downloaded from Github wouldn't work with custom-compiled builds downloaded here because DLLs are incompatible. I dunno why they only provide the executables on Github and not everything, but well...

Edited January 19, 2023 by NightFright

[rfomin]

You can get DLL's here: https://github.com/coelckers/prboom-plus/releases/download/windows_dependencies/windows_dependencies.zip

[NightFright]

I am aware of it, but aren't they kinda outdated by now? These were built back in 2020. There are newer versions of those DLLs available by now, especially for the SDL2 libraries. However, those won't work unless you recompile everything.

 

*UPDATE*
Latest PrBoom+ binaries for Win x64 in the attachment, combined with a mix of the "Windows Dependencies" package from Github and newer DLLs from custom builds recently posted here (latest from Dec 4, 2022). Not all DLLs have been replaced since otherwise the whole package would stop working, but at least the main ones are all a lot newer now, including SDL2 (2.26.0) and the PortMidi library.

 

prboom+ (v2022-12-30).zip

Edited January 19, 2023 by NightFright

[Never_Again]

Latest dev builds, as of commit fafebce (Dec 30 2022).

 

Noteworthy changes since last official release (v2.6.2um, February 11 2022):

- sort resolutions by width first and associated fixes
- consider the case of only one available resolution
- fixed integer overflow that caused jagged motion after running for about 26 minutes
- UMAPINFO: fixed par times not loading for finale levels
- generate mixer buffer size from sample rate
- fixed mouse stuttering with uncapped framerate and VSync
- convert uppercase shortcut keys from UMAPINFO
- added complevel hints
- UMAPINFO: fixed nextsecret inconsistencies
- free temp footer buffers
- fixed mid-texture judder when upper and middle textures overlap
- optionally include wipe effect in video capture
- allow to -warp to MAP00
* print a message to console when demo recording starts
* fixed PortMidi level transitions
* added proper SysEx support to PortMidi
* changed player arrow color in automap to match vanilla
* fixed pitch-bend typo for PortMidi
* added configurable reverb and chorus for PortMidi
* adjusted music volume slider to match vanilla
* use non-linear scaling for high volume levels
* adjust PortMidi volume slider to match midiOutSetVolume
* UMAPINFO: bring par times fix in line with Woof!
* only load one IWAD
* GL: initial attempt at fixing sky bleed when sky sector ceiling is lower than 
  front sector floor 
* set all notes/sounds off prior to SysEx reset
* fixed MIDI looping when using reset delay
* fixed UMAPINFO endgame crash
* fixed FluidSynth mode and polyphony 
* use colormap for duplicate detection
* fix UMAPINFO e2m8 default endpic
* PortMidi: use channel volume control, remove extra delay after reset
* reset temp column variable on buffer reset
* replace win_fopen.c with wrappers used in Chocolate Doom
* PortMidi: preserve timing when filtering SysEx; default to GM mode
* added fix for MS GS Synth bug

* - new since my last dev build (June 22)

+ console output

 

32-bit:

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

 

64-bit:

prboom-plus-20221230-w64.zip (Mediafire)

 

Required DLLs included. See the accompanying TXT files for details.

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

Edited January 19, 2023 by Never_Again

[Never_Again]

Good point about the Windows dependencies package not being updated. If some of them (cough ... SDL2 ... cough!) happen to introduce bugs how is the user expected to detect and report those bugs?

 

MSVC bins as default for the Github Actions is a pretty odd choice. I was under the impression that most port devs ran some flavor of Linux.

[NightFright]

Weird. This build works if I copy it into a standalone folder and add the IWADs, but it I want to use it with a launcher (e.g. DoomRunner, command line e.g.: ./prboom-plus.exe -iwad "../../iwad/doom.wad"), with the IWADs in a different folder, the game doesn't launch.

Edited January 19, 2023 by NightFright

[Never_Again]

Do you have DOOMWADDIR set properly in your enviroment? Point it to the folder where your IWADs are and use the absolute path. You won't need to specify a path in the launcher then.

[NightFright]

I can't find that in prboom-plus.cfg, or is it somewhere else? Anyway, with the build I posted above, there was no need to change any config entry.

[Never_Again]

It's under Computer->Properties->Advanced System Settings->Environment variables. %DOOMWADDIR% takes a single path and is for IWADs. %DOOMWADPATH% can have multiple paths separated by semicolons and is for PWADS:

SET DOOMWADPATH=C:\DOOM\WADS\1;C:\DOOM\WADS\2

Both can be overriden from the command prompt or via batch files.

[mikeday]

1 hour ago, NightFright said:

Weird. This build works if I copy it into a standalone folder and add the IWADs, but it I want to use it with a launcher (e.g. DoomRunner, command line e.g.: ./prboom-plus.exe -iwad "../../iwad/doom.wad"), with the IWADs in a different folder, the game doesn't launch.

Does it work if you use an absolute path for the iwad? (That is, no .. or . in the path)

[NightFright]

These two variants won't work, either (if I have doom.wad in an "iwad" subdir within the PrBoom+ folder):

prboom-plus.exe -iwad iwad/doom.wad

prboom-plus.exe -iwad "iwad/doom.wad"

 

It's like something in this build prevents subdirs/relative paths to be used.

Edited January 19, 2023 by NightFright

[mikeday]

Does it work if you call prboom-plus from the command line manually? The launcher might be altering the specified relative paths. I would still specify the iwad using an absolute path (C:\<path to iwad directory>\doom.wad) in the launcher.

[NightFright]

I did the attempts described above with a batch file, so yeah, command line it was. No launcher had been used whatsoever. But well, with full file path it wouldn't work, either.

Edited January 19, 2023 by NightFright

[Never_Again]

There's nothing in my builds that would prevent use of relative paths. You or the launcher, when you use it, don't specify the correct working (current) dir. For a batch file it would like this:

 

@echo off
d:
cd d:\doom\prboom-plus
prboom-plus.exe <your params here>

if D:\doom\prboom-plus is your prboom-plus dir.

 

Once again, you can save yourself the trouble of specifying any paths by setting %DOOMWADDIR%. Here is a step-by-step tutorial on how to do it under various Windows versions. The var it deals with is %PATH% but the principle and the steps are exactly the same.

[mikeday]

Ah, I thought you said above you were using a launcher. In that case, can you capture the command line output and share it here? Add “> output.txt 2>&1” to the end of the command that you’re using to launch prboom-plus. The output should show up in output.txt in the directory where you invoke the batch file.