PrBoom+ 2.6.66 (Jun 20, 2023)

4 hours ago, fabian said:

 

If with "as advertised" you mean "according to the specs", it is compliant. Fullscreen graphics instead of flats as intermission backgrounds have only been added to the spec after the feature has been implemented in PrBoom+ after the 2.6um release. Sorry, but you'll have to wait for 2.6.1um or use one of the unofficial builds provided here.

No worries!  I look forward to it, and thanks for the update!

4 hours ago, maxmanium said:

Are there any plans to improve the netcode for this port (since it's apparently bad)?

This has been discussed a bit on the speedrunning discord (since people would love to do coop runs more easily). It's definitely something that we "plan" to do, but I wouldn't expect anything soon.

Latest Win32 dev build, as of commit a2cdfe5 (March 20 2021).

Noteworthy changes since last dev build (March 17 2021):

* removed lowpass-filter item from menu
* fixed P_SetMobjState stack, fixes crash on mayhem18p.wad/m18p31-1509.lmp
* fixed crash in automap on certain maps (e.g. Sunlust MAP01) when using GL renderer,
  Thing Appearance = Icons and 2xIDDT
* fixed menu intermission desync

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

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

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

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

18 hours ago, LincolnPark96 said:

Sorry for the ignorance, but do you know if UMAPINFO allows to see the episodes and intermission screens of wads like Valiant, Ancient Aliens or Eviternity, or is it something impossible to implement for this source port?

umapinfo.zip
There you go!

Those were made long ago, so something may not work with the update coding.

But its nothing hard to fix if thats the case.

Cool, the one from valiant seems to work fine (both episode and intermission screens), while the other wads don't display well on the screen. Even so, it's very good.

16 minutes ago, LincolnPark96 said:

Cool, the one from valiant seems to work fine (both episode and intermission screens), while the other wads don't display well on the screen. Even so, it's very good.

 

Try adding episode = clear above the first episode

Yeah, that was the problem, thank you very much. Also I have to add episode names for Ancient Aliens UMAPINFO, because they weren´t in the corresponding line of code.

I know it's off-topic but, could anyone help me figuring out the video capture feature? I can't seem to make it work.
I have mkvmerge.exe, due to installing mkvtoolnix, oggenc2.exe and x264.exe all in the same folder as the sourceport, and my bat file is as such: prboom-plus -timedemo test -viddump foo.mkv
I'm on Windows 10 64-bit. Any help would be greatly appreciated guys.

Demo-to-video capture is covered in prboom-plus-usage.txt included with the official release.

There's also a relatively recent guide for using HW encoding with it here: prboom+ -viddump GPU hardware encoding.

Latest Win32 dev build, as of commit a43dff0 (March 22 2021).

Noteworthy changes since last dev build (March 20 2021):

* fixed crash when leaving menu in Chex Quest
* initialize map title widget with generic map lump name
* make "Next Level" key simply increase map number if already outside regular 
  level transition range
* check for next level in IDCLEV cheat before announcing it
* make sure "Next Level" key never warps to a non-existent map

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

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

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

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

Good update, particularly nice to be able to minimize to windows and take screenshots now. I managed to integrate the chapter select umapinfos in those 3 wads, is there such thing for other wads too?

15 hours ago, Never_Again said:

Demo-to-video capture is covered in prboom-plus-usage.txt included with the official release.

There's also a relatively recent guide for using HW encoding with it here: prboom+ -viddump GPU hardware encoding.

I've been following the instructions on the usage textfile but, as of now, I've been unable to make it work.
Thank you for the help anyway Never_Again.

I don't know if this has been brought up before, but I've noticed the chainsaw swaying animation is very choppy compared to the other weapons. Was it intentional?

On 3/21/2021 at 11:13 PM, Adamast0r said:

I know it's off-topic but, could anyone help me figuring out the video capture feature? I can't seem to make it work.
I have mkvmerge.exe, due to installing mkvtoolnix, oggenc2.exe and x264.exe all in the same folder as the sourceport, and my bat file is as such: prboom-plus -timedemo test -viddump foo.mkv
I'm on Windows 10 64-bit. Any help would be greatly appreciated guys.

I just gave it whirl using the latest build and it output a file just fine. But I'm using ffmpeg and mp3 so I also have ffmpeg.exe and lame.exe/lame_enc.dll in the folder.

these are my cfg settings
 

and this is what my bat looks like
 

37 minutes ago, molecicco said:

I don't know if this has been brought up before, but I've noticed the chainsaw swaying animation is very choppy compared to the other weapons. Was it intentional?

Swaying works by calling a function that repositions the sprite (among other things). For most weapons, this function is being called every tic when the weapon is idle. This is achieved by having one idle state that loops on itself, and its duration is 1 tic.

However, chainsaw is unique in that it has an animated idle sequence. That animation is choppy, and you can't call any functions between states, thus bobbing is choppy as well.

It's possible to fix this in DEHACKED, but it requires additional states and some care.

Engine-side solution would require overriding vanilla logic for bobbing and making it independent from the aforementioned function. It sort of already is, since there's an option to always sway the weapon, even when it's firing, but I just checked and it doesn't affect the chainsaw idle sequence.

1 hour ago, Da Werecat said:

It's possible to fix this in DEHACKED, but it requires additional states and some care.

Does this port support extended DEHACKED? It would be cool if it did (I think it should at this point), and that way anyone who wants it can autoload a patch that uses the last states in that table to smooth out the animation.

It's been a while since I looked at vanilla state table, but there could be enough unused states to implement the fix.

However, it would break demos. Since the function also detects the attack button, choppy idle animation makes the chainsaw less responsive than other weapons. Something to keep in mind.

25 minutes ago, Da Werecat said:

It's been a while since I looked at vanilla state table, but there could be enough unused states to implement the fix.

 

However, it would break demos. Since the function also detects the attack button, choppy idle animation makes the chainsaw less responsive than other weapons. Something to keep in mind.

Was wondering if that was the case.

@maxmanium Yup, DEHEXTRA is supported, so there's plenty of states to spare for a quick DIY fix. Just don't try and record/playback any demos with it. :P

On 3/23/2021 at 8:02 PM, siteod said:

 

I just gave it whirl using the latest build and it output a file just fine. But I'm using ffmpeg and mp3 so I also have ffmpeg.exe and lame.exe/lame_enc.dll in the folder.

 

these are my cfg settings
 

  Reveal hidden contents

# Video capture encoding settings
cap_soundcommand                  "ffmpeg -f s16le -ar %s -ac 2 -i pipe:0 -acodec libmp3lame -aq 4 temp.mp3"
cap_videocommand                  "x264 -o output.mp4 --crf 23 --muxer mp4 --demuxer raw --input-csp rgb --input-depth 8 --input-res %wx%h --fps %r -"
cap_muxcommand                    "mkvmerge -o %f output.mp4 temp.mp3"
cap_tempfile1                     "temp.mp3"
cap_tempfile2                     "output.mp4"
cap_remove_tempfiles              1
cap_fps                           60

 

and this is what my bat looks like
 

  Reveal hidden contents

prboom-plus -iwad doom -complevel 3 -file vsmooth2020-05-12.wad Doomgirl.wad -timedemo ep1-1919.lmp -viddump ep1-1919crf24nearmip.mkv

 

I tried it your way, but no dice. Thank you for all the help anyway.

what do your video_stdout and mux_stdout txt files say, that might give some clues as to what's going wrong

On 3/25/2021 at 2:43 PM, siteod said:

what do your video_stdout and mux_stdout txt files say, that might give some clues as to what's going wrong

I might get back at it later, as I deleted those at the time. Nonetheless, I really appreciate the help.

In an unrelated topic: since this awesome fork of PrBoom supports UMAPINFO and such, I'd like to know if it could be compatible with this, to use in Thy Flesh Consumed:

UDEP4FIX.rar

thyinterpic.rar

Are you guys inclined to make PrBoom+ as vanilla as possible, I mean like, indistinguishable from Chocolate Doom or dos? Don't Doom purists want something like that?

But... they already have it. As Chocolate Doom.

You mean `-complevel 2 -geom 320x200`?

Latest Win32 dev build, as of commit 6cd80a9 (March 31 2021).

Noteworthy changes since last dev build (March 22 2021):

* reformatted umapinfo.txt so that it is easier to read in plaintext
* fixed custom episode select for Doom 2
* fixed shifting automap markers

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

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

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

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

Say, would it be possible to add a savegame directory, just like the screenshots one? I think the option to delete saves in-game is great but, I was just wondering if this would be something easy to implement, for organisation purposes.

2 hours ago, Adamast0r said:

Say, would it be possible to add a savegame directory, just like the screenshots one? I think the option to delete saves in-game is great but, I was just wondering if this would be something easy to implement, for organisation purposes.

This functionality kinda already exists: https://www.doomworld.com/forum/post/2277217

24 minutes ago, Rathori said:

This functionality kinda already exists: https://www.doomworld.com/forum/post/2277217

Much obliged. Didn't know about that at all.
And is there a way to change the player's name, as in other source ports? I really can't find that option in the configurations.

Does a player name variable get used anywhere in PrBoom+? I don't believe it has death messages, but admittedly I don't play MP so I'm not aware of what it displays on one player killing another in DM - I'd have assumed nothing, though.