This is Woof! 14.5.0 (Apr 30, 2024)

[rfomin]

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 June 2 by rfomin

[OnymynO]

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!

[costadevale]

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

[rfomin]

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.

[Gibbitudinous]

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.

[rfomin]

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?

[Gibbitudinous]

No, I'm on Windows 10.

[Shepardus]

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

[pantheon]

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 June 7 by pantheon

[elborbahquarama]

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!!

[pantheon]

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. 

[Gibbitudinous]

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.

[ceski]

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.

 

[deeeefers]

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

[liPillON]

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?

 

[rfomin]

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

[GarrettChan]

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.

[rfomin]

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

[ceski]

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.

[GarrettChan]

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?

[ChopBlock223]

On 6/11/2024 at 8:07 AM, ceski said:

 

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.

Oh, this is cool, I'll have to give this a look.

(I've been really busy, so I haven't been present)

[costadevale]

On 6/7/2024 at 3:24 AM, rfomin said:

 

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.

If you don't mind me making a suggestion...

 

Since the idea of a level table was brought up not too long ago, and since this port aims to have a clean UI... why not merge both the level table and the level selection menu?

 

My idea is like this: an option to choose the level (like the automap colour preset), toggles for things like -nomonsters or -solo-net, with text below that shows your stats for that level. For the multiplayer setup, just make a submenu. International Doom has something similar, although only for single-player.

[maxmanium]

Not sure if this is known but the SPECHITS cheat crashes and throws an error:

 

P_MapStart: tmthing set!

[rfomin]

On 6/11/2024 at 10:08 PM, GarrettChan said:

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

 

I can't reproduce it. What PWAD/complevel/multiplayer options?

 

8 hours ago, costadevale said:

Since the idea of a level table was brought up not too long ago, and since this port aims to have a clean UI... why not merge both the level table and the level selection menu?

 

Yes, I was thinking something like this.

 

Integrating the multiplayer menu would require a lot of rework, it would take some time.

 

1 hour ago, maxmanium said:

Not sure if this is known but the SPECHITS cheat crashes and throws an error:

 

P_MapStart: tmthing set!

 

Works for me, what PWAD/map/complevel?

[maxmanium]

11 hours ago, rfomin said:

Works for me, what PWAD/map/complevel?

 

I noticed it on several maps but they were all cl9. Most recent is resurge.wad map15.

[rfomin]

On 6/15/2024 at 10:36 PM, maxmanium said:

I noticed it on several maps but they were all cl9. Most recent is resurge.wad map15.

 

Thanks for reporting this, it will be fixed in the next release.

[Blue Phoenix]

I have done some experimenting with BRGHTMPS and here are some of the results

Spoiler

 

 

There are 2 notable limitations:

1: the bright state flags have to be removed via DEHACKED for any of this to work

2: making the imp's eye or knights/barons flame fists glow would also make their blood glow,  so I have to make copies of their death animations under different names

 

If BRGHTMPS could refer to specific frames of a sprite and ignore the bright flag, things would be easier to work with.

[rfomin]

3 hours ago, Blue Phoenix said:

If BRGHTMPS could refer to specific frames

 

I think it could be done with STATE (see autoload/doom-all/brgtmps.lmp). You need the frame/state number, you can get it from the table in the docs/boomdeh.txt file.

[Blue Phoenix]

41 minutes ago, rfomin said:

 

I think it could be done with STATE (see autoload/doom-all/brgtmps.lmp). You need the frame/state number, you can get it from the table in the docs/boomdeh.txt file.

First thing I tried and it didn't work. Tried again just now and still doesn't work.

[rfomin]

1 hour ago, Blue Phoenix said:

First thing I tried and it didn't work. Tried again just now and still doesn't work.

 

Right, I looked at the code, currently it only works for weapons. I think we will make it work for all sprites.