PrBoom-Plus, ver. 2.5.1.4

[kb1]

On 10/14/2018 at 7:38 PM, Spectre01 said:

I don't wanna start no thing here, but why is the sound stacking so awful? The options seem to be either to use 8 channels and get a lot of sounds cut off or using the default 32 and get your eardrums popped by alerting a group of Revenants. Even 5 Arachnotrons walking around is exessively loud and annoying. And don't get me started on playing Scythe map26 on anything above 8 channels. This is not an issue in other ports like GZDoom when using even 64 sound channels.

It's kind of a bizarre thing: When mixing multiple exact sounds that start at exactly the same time, it becomes very difficult to avoid audio clipping. Most sounds are recorded near the amplitude limit, so when playing 2 exact sounds at the same time, you're essentially doubling the amplitude.

 

More sophisticated mixers will scale each sound, and it's even possible to mix at a higher range, detect clipping, and scale the amplitude accordingly, not unlike a compressor. But even then, you have issues like the sounds being played at inconsistent different volumes. Fortunately, because there are usualy a lot of sounds happening at this time, it's not easily noticeable.

 

There are other approaches: One approach is to detect this specific case, and avoid mixing the same sound multiple times, and instead play the single sound at full volume. Another approach is to introduce a tiny random delay between the playing of duplicate sounds. If you don't use randomness, you end up with frequency-specific spikes that clip.

 

A final approach is pitch bending.

 

Unfortunately, no approach is perfect. It's something that I investigated a bit, a while back. I haven't heard of a lot of work being done in this area, but it's something that deserves some serious testing and study. Interestingly, vanilla Doom's "one sound per object"/"Silent BFG" limit allowed it to avoid this specific issue, whether it was intentional or not.

[kb1]

On 10/14/2018 at 3:17 PM, Grazza said:

That is exactly what is supposed to happen. It is not a bug. It also works that way in vanilla and choc. If you are not observing it, then it can only be due to different mouse sensitivity.

Thanks for confirming this. A fix for this wouldn't bother me in the least, but I imagine it would bother someone. It creates a bit of "hysteresis" - a series of "dead spots" that might help someone aim very carefully.

 

A menu option would make everyone happy, though.

[StevenC21]

Damn, this thread is like reading ancient history. Nice bits of IRL Doom lore here.

[printz]

I've found an oversight in GLBoom+, compared to PrBoom+. When using floor/ceiling light transfers, under software PrBoom+, sprite brightness is the average of the floor and ceiling lights. However, under GLBoom+, this detail is ignored and the sprite brightness is just the nominal sector light level.

 

Here's how it should look:

 

Under GLBoom+ it's like this:

[VGA]

Test wad?

[printz]

@VGA Here you go: 

testlight.wad.zip

[VGA]

Looks proper for me in the version of glboom+ I had from 2016 and the newest one I just downloaded from the site. The barrels don't look black like in your screenshot.

[Grazza]

How it looks depends on the complevel, due to this being an MBF feature. You need to using complevel 11 or above for MBF features to be active (or available).

[Spectre01]

I was trying to play Bloody Steel in PRBoom+ until encountering a bunch of visual glitches and realizing it's meant to be played in OpenGL mode. Booted up GLBoom+ and for some reason the menu music and the tracks for the first few maps have some kind of popping/crackling/static effect going on in the background. Doesn't happen in the PRBoom+ .exe. Any idea what could be causing this?

[NeedHealth]

Had once a bug where I pressed the movement keys quick enough to start spinning around. Looked liked a input delay issue.

 

I can not reproduce it, no.

[CorianderCastor]

I found an issue in prboom-plus-2.5.1.5.r4526-win32.

 

If one binds a weapon slot with two weapons to the mouse wheel and then selects that slot with the wheel, then the game just keeps cycling through the weapons in that slot.

 

Sorry if this is a known issue.

[waverider]

Has PR/GLBoom+ been discontinued permanently? Seems so, no updates since May -17. :( 

 

It's no doubt my favorite source port but I wish a couple of things could be fixed/changed.

 

For instance, there's no true 21:9 aspect ratio support, textures look really stretched when looking at them from an angle. Also, GL support seems to be non-functional in the last v2.5.1.5 release. Amongst a couple of other things.  

 

Would be awesome if the program was to be resumed one day.

[seed]

36 minutes ago, waverider said:

Has PR/GLBoom+ been discontinued permanently? Seems so, no updates since May -17. :( 

 

Fabian pretty much shot down the rumors surrounding PrBoom+'s death there. The relevant quotes:

 

Quote

"Is that even true though? I see people keep mentioning this but so far I have not seen a trustworthy source saying it has ceased development."

Quote

"Andrey just applied some patches I sent to him. So, it's not dead, just moving very slowly."

Spoiler

"What were those patches for?"

Quote

"Support for recent libdumb releases and fixes for some compiler warnings iirc."

 

Also, I see there was almost a whole 5yrs gap between version 2.5.1.3 and 2.5.1.4. So, I guess development is just really, really slow, but that doesn't mean it's dead. At least, not at this time.

[waverider]

Quote

26 minutes ago, Agent6 said:

Fabian pretty much shot down the rumors surrounding PrBoom+'s death there. The relevant quotes:

 

Ah, that's good news! I assume a PM to Andrey might be a good idea then. :) Thanks!

[TheMightyHeracross]

I'd imagine PrBoom+ in its current state simply isn't in as much need of constant maintenance, feature additions, etc as ports such as GZDoom, Eternity, or even Doom Retro. It's understandable that it wouldn't see as much activity.

[Beezle]

Is there a way to play Keyboard + Mouse but without looking up and down, and disabling forward and backward movement? Just using mouse to look left and right.

[seed]

12 minutes ago, Beezle said:

Is there a way to play Keyboard + Mouse but without looking up and down, and disabling forward and backward movement? Just using mouse to look left and right.

 

Absolutely, but I don't remember which option affected this. It should be where the mouse settings are though, somewhere.

[rehelekretep]

mouse settings, set vertical aim sensitivity to 0/slide the bar all the way to the left.

[Paul977]

I have a strange graphic issue concerning prboom+2.5.1.4 (software mode not glboom); all of a sudden looks like the colors of some stuff (like imp and caco fireball, the soulsphere, arch-vile flames) are changed. Someone know what could have been caused this and eventually how to fix ?

Here an example screenshot:

 

 

 

 

 

[ketmar]

this is may be due to some pwads you're loaded, with replaced colormap.

[Ribbiks]

2 hours ago, Paul977 said:

I have a strange graphic issue concerning prboom+2.5.1.4 (software mode not glboom); all of a sudden looks like the colors of some stuff (like imp and caco fireball, the soulsphere, arch-vile flames) are changed. Someone know what could have been caused this and eventually how to fix ?

Here an example screenshot:

 

prb+ will use the TRANMAP lump in a wad if one is provided. If one is not present then it will defer to the last one that was computed and saved in it's local directory (as tranmap.dat). What is unfortunate, is that some wads will introduce a palette with color ranges shifted around, but will not provide an associated TRANMAP, and so the mismatch between the one you have cached and the one that would fit the color scheme of the wad can create color artifacts for translucent sprites in software gfx. The opposite can also occur, if somehow your default TRANMAP was built while you were playing a wad with a custom palette, all of a sudden every normal other wad will have these artifacts (this happened to me during the design of sd20x7 and it took me a bit to figure it out :p).

 

you can solve it by deleting tranmap.dat (mine was stored in ~/.prboom-plus/). In my personal copy of prb+, I edited that section of the code to just have it rebuild the tranmap every time, just in case I'm playing a wad with a custom palette that doesn't include a tranmap. (it's 2019, recomputing it every time is a trivial computational expense)

[fabian]

Another problem is that it only compares the first 256 bytes of the current palette with the one cached on disc in tranmap.dat. A complete palette, though, takes 256*3 bytes. 

[Paul977]

Yeah, deleting tranmap.dat solved the problem, thanks Ribbiks

[dmslr]

@fabian if it were possible would you continue the developing of prboom?

[seed]

12 hours ago, dmslr said:

@fabian if it were possible would you continue the developing of prboom?

 

It's not dead yet.

[dmslr]

4 hours ago, seed said:

 

It's not dead yet.

Ah, ok. Well we will be waiting for stable 2.5.1.5

[seed]

1 minute ago, dmslr said:

Ah, ok. Well we will be waiting for stable 2.5.1.5

 

2.5.1.5test is very stable as it is imo, never had any issues with it.

 

Next version will probably be a different number.

[dmslr]

Please someone help. There is the .patch-file I want to put in prboom+ but dunno how to do

[Ribbiks]

26 minutes ago, dmslr said:

Please someone help. There is the .patch-file I want to put in prboom+ but dunno how to do

 

It's reasonably straightforward if you're comfortable compiling prb+ from source. However, seeing as the version of prb+ that this patch is for is ~6yrs old at this point, you'd be better off going file by file and replicating fabian's changes. I'd offer to make them myself and build it for you, but unfortunately I'm an idiot when it comes to anything involving Windows -.- (nor do I have access to icc, which, if I understand correctly, is responsible for a decent chunk of prb+'s very high performance in official builds).

[fabian]

This is the latest SVN snapshot with the patch applied, compiled with GCC 7.4.0 in an MSYS2 environment.

Please note that the patch was very preliminary and works only with the OpenGL renderer.

prboom-plus_2.5.1.5+svn4539+dfsg1+colored-blood2.zip