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

This is Woof! 14.5.0 (Apr 30, 2024)

Recommended Posts

Posted (edited)
18 hours ago, OnymynO said:

It doesn't launch. :(

 

Trying to run it through the terminal yields this:

 

I tried new approach to build AppImage, it should work with old glibc but has new OpenAL. Try the "AppImage" artifact from this page: GitHub Experimental, may work worse.

 

Edit: this is better version: GitHub

Edited by rfomin

Share this post


Link to post
6 hours ago, rfomin said:

 

I tried new approach to build AppImage, it should work with old glibc but has new OpenAL. Try the "AppImage" artifact from this page: GitHub Experimental, may work worse.

 

Edit: this is better version: GitHub

 

So far, so good. Thanks!

Share this post


Link to post

Is there a reason as to why the 'warp' option in the setup .exe was removed? Just wondering.

Share this post


Link to post
11 hours ago, costadevale said:

Is there a reason as to why the 'warp' option in the setup .exe was removed? Just wondering.

 

woof-setup.exe was created for network play only, and we have plans to integrate the multiplayer setup into the main exe. Maybe we should create an in-game level selection menu.

Share this post


Link to post

So I've noticed that Woof has had this issue for a while with pops showing up at the end of some sound effects that simply aren't there in other source ports (e.g. many of the sound effects in Chex Quest).

 

I'm wondering if there's some option I can change to fix this or if it's just an issue with the port.

Share this post


Link to post
16 minutes ago, Gibbitudinous said:

So I've noticed that Woof has had this issue for a while with pops showing up at the end of some sound effects that simply aren't there in other source ports (e.g. many of the sound effects in Chex Quest).

 

Are you running Linux?

Share this post


Link to post

I think many of Chex Quest's sound effects do have artifacts at their end (I can hear it playing them back in SLADE or in a media player after exporting to WAV), which was fixed in Chex Quest 3 (including Vanilla Edition). I'm not sure why I can hear them in some source ports but not others, though. I can hear it in GZDoom and Woof, but not dsda-doom or Crispy Doom (I tested by walking out of the starting room in E1M2 and waiting, since the monsters' roaming sound is one of the affected sounds).

Share this post


Link to post
6 hours ago, Gibbitudinous said:

No, I'm on Windows 10.

 

I posted an issue on Github about this. I get the same thing on Windows 10. At first I thought it could be an OpenAL issue, but it's present even in SDL Mixer versions of Woof. For now, here's a WAD with all of the sound effects from Vanilla Edition. Loading it like "woof.exe -iwad chex.wad -file chex_soundfix.wad" should overwrite the old sounds. Hopefully nothing else was changed for Vanilla Edition or anything, I am not Chex-experienced enough to tell.

 

Edit: Actually, DSPOSACT was changed from the funny shoesteps to a squelch sound in the "remastered" effects. Here's "v2" of the fix with the proper footsteps, all I did was fade out the end in Audacity. I also removed the extraneous sounds added by Chex 3 (there's 20 extra sounds, probably wouldn't hurt anything but still). So, hopefully this is an exact replacement with no pops.

 

chex_soundfix_v2.zip

Edited by pantheon

Share this post


Link to post

are the chex quest pops subjective tinnitus (produced by our brains) or objective tinnitus (physically real sounds)? scientists are tearing up each other on the matter during breakfast while eating their delicious chex cereals!!

Share this post


Link to post
49 minutes ago, elborbahquarama said:

are the chex quest pops subjective tinnitus (produced by our brains) or objective tinnitus (physically real sounds)? scientists are tearing up each other on the matter during breakfast while eating their delicious chex cereals!!

 

Essentially, it's just one of the classic problems caused by a bad fade. Things like headphones that produce sound don't like beginning or ending at non-zero amplitude, since it basically tells the stuff moving to emit sound to go from producing something back to nothing, instantly. The really bedeviling part is how the same exact sounding "pops" can come from "bad" sound effects themselves (pictured in that Github issue), or from the way even "perfect" audio files can be handled (i.e. SDL mixer instantly cutting interrupted sounds so spamming use on a wall starts popping). OpenAL has mitigations for the latter, Woof has some special fade handling for the former which, as far as I know, is still unique among Doom ports. 

Share this post


Link to post
18 hours ago, Gibbitudinous said:

I mentioned just Chex Quest because of how well-known it is, but I should mention that I noticed this in Doom Part 2 as well. Tried it in DSDA-Doom and International Doom and neither had this issue.

 

Thanks for the report, this will be fixed in the next release. The underlying issue actually affects most source ports, although it's not always apparent because they all handle sound trimming differently. Woof now matches vanilla Doom's method. There's also some additional click prevention which is unique to Woof I believe:

 

 

Some additional details:

 

Spoiler

Vanilla Doom's sounds have dummy data attached at the beginning and ending of each file. This is a side effect of how they were converted from .wav files to "Doom format" lumps. When vanilla Doom loads a sound, it trims off the dummy data blindly (without checking it).

Chocolate Doom and its derivatives, including Inter-Doom, behave this way too. PrBoom+ and it's derivatives, including DSDA-Doom, trim incorrectly and only at the end of each file. Woof (previously), Eternity Engine, and Slade trim correctly but only after verifying that it's actually dummy data. GZDoom doesn't trim at all.

Unlike Slade, older wad tools don't add dummy data, so in many cases a portion of the real sound is unintentionally trimmed when the game loads the file. Sometimes the trimmed portion contains a non-zero amplitude for the first or last sample, which would normally cause a "click" if left in. However, in other cases the trimming actually causes new clicks!

Chex Quest was likely created with whatever tools were publicly available at the time (e.g. DeuTex). Close examination of the sounds reveal that they lack the dummy data described above. The Chex Quest developers were likely unaware their sounds had clicks because the trimming hid it from them. This applies to many other wads with custom sounds, including the one you linked (the sounds in that wad have a lot of other unrelated issues too).

With Woof, the dummy data check was removed so sounds are trimmed like vanilla Doom now. Additionally, a separate check was extended to prevent clicks from non-zero amplitudes. So this strange issue is solved now.

 

Share this post


Link to post

hi team, I've noticed that current devbuilds for windows aren't statically linked (several lib*.dll files are generated instead of a single woof.dll)

will this be the case for release builds too?

 

Share this post


Link to post
On 6/9/2024 at 12:37 AM, deeeefers said:

will woof have a level table at some point like dsda doom? It's a very helpful menu

 

I will try to experiment with the level table menu.

 

9 minutes ago, liPillON said:

hi team, I've noticed that current devbuilds for windows aren't statically linked (several lib*.dll files are generated instead of a single woof.dll)

will this be the case for release builds too?

 

 

The main build is still static: GitHub

Share this post


Link to post

Is it supposed to show the messages from the other player(s) when playing coop on vanilla?

At least before, it was not the case for Woof or whatever other sourceports.

Share this post


Link to post
7 hours ago, GarrettChan said:

Is it supposed to show the messages from the other player(s) when playing coop on vanilla?

At least before, it was not the case for Woof or whatever other sourceports.

 

What kind of messages? There was a bug with "you need a key" messages, but we fixed it in Woof 12.0.1

Share this post


Link to post
On 3/8/2024 at 2:26 AM, ChopBlock223 said:

One of these.

Specifically the button above the the analog stick (Joy17), which I like mapping the automap key to when playing with GzDoom.

I found I could bind it to pressing right on the DPad in Woof, so not a huge deal, but consistency is always nice.

 

I finally started working on a solution for this. If you have a few minutes to test your controller, I can use the "mapping" info for Woof so the buttons are configured correctly. Details are here and the dev build is here (log in, scroll down to artifacts, download the Win-64 build). If this works okay, I'll develop it further and streamline things. As an added benefit, with the mapping info I can reach out to the SDL devs to request support for your controller in a future SDL release. That means (ideally) it will eventually be supported automatically by any source port that use SDL, and likely many other games too.

Share this post


Link to post
13 hours ago, rfomin said:

 

What kind of messages? There was a bug with "you need a key" messages, but we fixed it in Woof 12.0.1

 Pick up messages, I think I reported it before, but it seems it's still there?

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
×