PrBoom+ 2.6.66 (Jun 20, 2023)

[Alper002]

3 minutes ago, Shadow Hog said:

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.

I'd guess the closest would be when chatting. If I recall correctly, When chatting in vanilla's multiplayer, it uses your player color (which is determined by player number rather than personal setting) as your name.

[adamastor]

I've been trying to change the chat sound that plays with the screenshots, but to no avail.
I think it's a good addition, and something I'd like to add to GZDoom as well, that the screenshot plays a sound confirmation, but I van't change it, even when placing the dsradio and dstink there with the new sound.
Therefore, I was just wondering how to pull that off, or even introduce a new sound with the proper commands.

[UnluckySpade7]

On 4/1/2021 at 6:55 AM, Never_Again said:

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.

The April 1st build is missing a libssp-0.dll for me, but the March 22nd one works fine.

Edited April 8, 2021 by UnluckySpade7

[adamastor]

37 minutes ago, UnluckySpade7 said:

The April 1st build is missing a libssp-0.dll for me, but the March 22nd one works fine.

Same thing happened to me, but I had one from the previous build.

libssp-0.rar

[Never_Again]

Latest Win32 dev build, as of commit 07925d6 (April 8 2021).

 

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

* allow translucent sprites on all complevels
* allow disabling predefined translucency on all complevels
* fixed flood HOM on certain maps (e.g. Plutonia MAP11, HR MAP01) (GL)
* fixed sky walls for cases with sky vs. sky toptextures (e.g. E4M6) (GL)
* fixed transparent spites being rendered incorrectly with transparent walls in view (GL)
* generate a default save-slot name when saving to an empty slot
* added mouse button binds for turn left/right

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

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

 

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

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

 

The missing DLL has been added, thank you for the reports, US7 and Adamast0r.

[adamastor]

This might be a dumb suggestion but, would it be possible to have a fps counter in the future? Or is that type of feature exclusive to source ports that have consoles, such as DOOM Retro or Mark V?

[T.Will]

1 minute ago, Adamast0r said:

This might be a dumb suggestion but, would it be possible to have a fps counter in the future? Or is that type of feature exclusive to source ports that have consoles, such as DOOM Retro or Mark V?

Type idrate and you'll get a FPS counter.

[adamastor]

1 minute ago, T.Will said:

Type idrate and you'll get a FPS counter. 

This is great. Thanks.
I think this fork is needing it's own, updated, usage.txt.
Anyway, do you know, by any achance, if there's a way to trim out the visplanes and sprites info and only get the fps display?

[vaa44]

Are there any plans to add brightmaps support in PrBoom like in Crispy Doom?

[Shepardus]

3 hours ago, vaa44 said:

Are there any plans to add brightmaps support in PrBoom like in Crispy Doom?

I'd recommend this wad, which does some colormap shenanigans to achieve a similar effect without having to code it in the source port itself.

[vaa44]

32 minutes ago, Shepardus said:

I'd recommend this wad, which does some colormap shenanigans to achieve a similar effect without having to code it in the source port itself.

For some reason, this wad doesn't work in GL. And it has " brightmaps " only for monster sprites, but not for items and textures.

[Da Werecat]

It involves a colormap hack. GL doesn't care about the colormap in this port. This effect is easy to detect though, so hardware emulation should be possible.

[Spectre01]

I have noticed these dev builds run around 20% slower compared to the DSDA releases on my end. Is this due to them being 32-bit? Also, fantastic work with the translucent projectiles.

[Firebert]

I made a custom advanced HUD

 

Make a backup before changing prboom-plus.wad

Open prboom-plus.wad in SLADE and go to "-PRBHUD-"

Highlight "hud 1" and the lines under it and paste this over it.

 

Paste this at the end of "-PRBHUD-" inside of prboom-plus.wad

hud 13
tracers 2 151
hudadd 2 159
keys 24 168
weapon 24 177
ammo_icon 4 -197
ammo 24 186
health -297 168
medict_icon_small -315 -179
armor -297 186
armor_icon_small -316 -197

Edited April 11, 2021 by Firebert
Better instructions

[Valboom]

One question: where is the "exclusive fulscreen" option?

 

[fabian]

9 hours ago, Firebert said:

I made a custom advanced HUD

Wow, that's a good one. Would you mind to file a PR for its inclusion? Does it work properly in all 4:3 and widescreen modes?

 

1 hour ago, Valboom said:

One question: where is the "exclusive fulscreen" option?

 

In the config file only. 

[maxmanium]

11 hours ago, Firebert said:

I made a custom advanced HUD

 

What the fuck? This is really good.

[Firebert]

5 hours ago, fabian said:

Would you mind to file a PR for its inclusion? Does it work properly in all 4:3 and widescreen modes? 

Done, yes it does.

[Never_Again]

On 4/9/2021 at 8:11 PM, Spectre01 said:

I have noticed these dev builds run around 20% slower compared to the DSDA releases on my end.

 

Interesting. How did you measure the difference - timedemo a specific demo? What renderer and video settings? Actual numbers would be helpful as well. 48fps vs. 60fps is not on the same scale as 800fps vs. 1000fps.

[Never_Again]

Latest Win32 dev build, as of commit 248bdc7 (April 12 2021).

 

Noteworthy changes since last dev build (April 8 2021):

* fixed sky scaling for non-standard sky sizes, e.g. Eviternity and Ancient Aliens (GL)

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

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

 

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

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

[Spectre01]

5 hours ago, Never_Again said:

Interesting. How did you measure the difference - timedemo a specific demo? What renderer and video settings? Actual numbers would be helpful as well. 48fps vs. 60fps is not on the same scale as 800fps vs. 1000fps.

I did a simple comparison of the spawn point in Sunlust map01 and 28. The former is not particularly demanding while the latter is a good performance benchmark. map01 was 118FPS vs 140 in DSDA and map28 was 45FPS vs 53. The former is not a big deal but 45 feels a lot choppier compared to 53, though neither is ideal. But I have noticed lower idrate FPS values across the board in several wads. This was done at 1920x1080 resolution in 8bit software mode in both ports (prboom-plus-20210412-w32 vs DSDA 0.18).

Edited April 13, 2021 by Spectre01

[vaa44]

6 hours ago, Never_Again said:

Noteworthy changes since last dev build (April 8 2021):

* fixed sky scaling for non-standard sky sizes, e.g. Eviternity and Ancient Aliens (GL)

Not fixed for me :

 

glboom skymode 0, fov=90

prboom

glboom skymode 0, fov=105

glboom skymode 3, fov=105

[Da Werecat]

Whoa, there's a cylindrical sky mode now? I missed that.

[vaa44]

27 minutes ago, Da Werecat said:

Whoa, there's a cylindrical sky mode now? I missed that. 

gl_skymode in prboom-plus.cfg

This parameter was in the config for a long time.

[JadingTsunami]

2 hours ago, vaa44 said:

prboom

glboom skymode 0, fov=105

 

Hmm, I think only this one (FOV>90, OpenGL, skymode=0) is still not rendering correctly when comparing the SW renderer and the OpenGL renderer. Otherwise the clipping at the top edge is part of the rendering tradeoffs made to adapt to freelook. During skymode=0 (automatic), artifacts won't appear unless freelook is enabled.

[vaa44]

48 minutes ago, JadingTsunami said:

Hmm, I think only this one (FOV>90, OpenGL, skymode=0) is still not rendering correctly when comparing the SW renderer and the OpenGL renderer.

In the first screenshot (skymode 0, FOV=90), the sky is stretched horizontally, which is not present in SW mode.

In skymode 3, the sky shifts vertically :

sw render:

gl render (FOV=90):

 

Edited April 13, 2021 by vaa44

[JadingTsunami]

3 hours ago, vaa44 said:

In the first screenshot (skymode 0, FOV=90), the sky is stretched horizontally, which is not present in SW mode.

 

Yes, I don't think the rendering will be identical between the modes for all cases. Right now they are close approximations to one another.

 

EDIT: Note I will look into this to see if some adjustment in the scaling can be made so it appears more consistent along with the FOV rendering changes; I'm not sure they will be identical for all cases though.

Edited April 13, 2021 by JadingTsunami

[vaa44]

18 hours ago, JadingTsunami said:

I will look into this to see if some adjustment in the scaling can be made so it appears more consistent along with the FOV rendering changes; I'm not sure they will be identical for all cases though.

Thanks!

[Trilby Trillion]

I found a very minor glitch that resets music tracks assigned with UMAPINFO when the map resets, such as after a death.

map E4M1
{
   music = "D_E4M1"
}

 

This doesn't happen with music reassigned with the usual method of replacing tracks, though. Again, a very minor glitch that doesn't really break anything, but just thought I'd bring it to your attention.

[JadingTsunami]

1 hour ago, Trilby Trillion said:

I found a very minor glitch that resets music tracks assigned with UMAPINFO when the map resets, such as after a death.

 

Nice find. Looks like this is because S_ParseMusInfo() called from P_SetupLevel() wipes out the current music structure.

 

Would you like to file an issue?