Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
fabian

PrBoom+ 2.6.66 (Jun 20, 2023)

Recommended Posts

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.

Share this post


Link to post

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.

Share this post


Link to post
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 by UnluckySpade7

Share this post


Link to post
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

Share this post


Link to post

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.

Share this post


Link to post

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?

Share this post


Link to post
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.

Share this post


Link to post
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?

Share this post


Link to post

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

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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

doom00.png

Edited by Firebert : Better instructions

Share this post


Link to post
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. 

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post
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).

Share this post


Link to post
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 :

prboom-plus_gl_fov90.png.e71d474e5c95c6238cd6a446cd5f574e.png

 

glboom skymode 0, fov=90

prboom-plus.png.1feb0c0c3e73e8b3b277058a18cec4b2.png

prboom

prboom-plus_gl_fov105.png.fd6b784ba5f89dd38d5a442d70fc800d.png

glboom skymode 0, fov=105

prboom-plus_gl_fov105_skymode3.png.6caf6f8dfaf1c90e85876532ac2303cd.png

glboom skymode 3, fov=105

Share this post


Link to post
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.

Share this post


Link to post
2 hours ago, vaa44 said:

prboom

prboom-plus_gl_fov105.png.fd6b784ba5f89dd38d5a442d70fc800d.png

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.

Share this post


Link to post
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:

sw.png.56a4b64811f467bc8c1d7d6c7035aea2.png

gl render (FOV=90):

gl.png.7c0107519486860c95ba4c6e0878a276.png

 

Edited by vaa44

Share this post


Link to post
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 by JadingTsunami

Share this post


Link to post
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!

Share this post


Link to post

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.

Share this post


Link to post
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?

 

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×