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

PrBoom-Plus, ver. 2.5.1.4

Recommended Posts

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.

Share this post


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

Share this post


Link to post

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:

light2.jpg.e5b799abec81bf6e292945bcd2008be5.jpg

 

Under GLBoom+ it's like this:

light1.jpg.12f1742a519743011d83438b1d06ee9e.jpg

Share this post


Link to post

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.

Share this post


Link to post

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).

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
×