This is Woof! 14.5.0 (Apr 30, 2024)

[Shepardus]

27 minutes ago, Average said:

I think I might've found in a bug in Woof.  Something seems not to trigger in Map 07 of Alien Vendetta.  I kill all the baddies and flick the 2 switches but the barrier to leave the level is still up and I can't finish it without no-clipping.

 

Nugget Doom couldn't even load the map and crashes out!

 

Just to make sure, I tried the map in GZD and DSDA and both ports handled it fine.

 

I'm using the latest dev build of Woof! if that makes any difference.

If you're using a non-vanilla complevel, that level needs the "comp_model" ("Use exactly Doom's linedef trigger model") compatibility option enabled due to a difference in how tag 667 works between vanilla and Boom. dsda-doom automatically applies options to certain known levels, this map among them, when playing with complevel 21, and GZDoom does something similar.

[liPillON]

hi! minor nitpick/curiosity: when using the fullscreen hud, the overlay automap is not drawn over the area usually occupied by the status bar

is this due to drawing routines' constraints or deliberate implementation choice?

 

[Average]

Thanks @Shepardus.  I was just on the MBF21 compatibility and never gave it any thought.

[pltr]

 

On 2/23/2023 at 1:21 AM, dististik said:

I think the way Woof! does colored numbers currently is by finding pixels in the red range and shifting them to the appropriate ranges for yellow, green, and blue (and maybe silver as well for invuln? but I'm less confident in that).

I tested your red range theory by making Speed of Doom's status bar numbers red instead of green and you're right! Woof only shifts red colors in ST bar numbers.

 

 

 

On 2/23/2023 at 1:21 AM, dististik said:

I'd mostly be curious in how Crispy's colored numbers work since they'd be a welcome addition in my book as I've recently started considering making my own additional wads for sets that don't recolor due to an assumed a lack of any red range.

 

I looked through Crispy Doom's source code and found this line which talks about hacking colors to full saturation. I don't know how to interpret the code or add something like it to Woof though.

 

[fabian]

Calm down, guys, I'm on it. ;)

[s4f3s3x]

Very minor request: would it be possible to have ENDOOM displaying in nearest? It's very cool that we got it fullscreen, but that strange smoothing kinda clash with the tasty and crunchy Woof experience. Right now the only one that does both is GZD (it's probably handled differently?)

[pantheon]

TL;DR: Fix sound clicks by adding tiny fades in/out to sounds to dodge clipping in the original files and prevent interrupted sounds from clicking?

 

I've still been thinking about the residual audio clicks in Woof and other SDL ports. This is my System Shock log of descending into madness. I recorded the clips below with 44.1khz set in Woof dev build and Windows playback settings, "best" resampling mode (other modes don't make a difference), cutoffs disabled, 32 max channels. I also tested with current desktop Fedora to see if maybe something's just weird in Windows but it made no difference. Here are some examples of the clicking: 

 

https://vocaroo.com/1oBMjQf0fxZg - Spamming use on a wall (not a usual gameplay event, but useful in that it doesn't click if played normally).

https://vocaroo.com/1awFmsh12ZjD - Despite my Woof version having this commit to fix chaingunner clicking, it's still there.

 

Where does this kind of thing not happen, or at least happens much less? DOSBox (I use DOSBox Staging with SB16 device/sbpro2 filter), in Woof when standing still listening to crushers after this commit, and in GZDoom.

 

For DOSBox Staging, I asked in their Discord and @johnnovak was super helpful explaining some of what they do with emulating Sound Blaster sound. A noticeable part of it is a 3.2khz low pass filter which does indeed squelch the clicks in Woof via a Windows equalizer (sample), but this is overkill and wouldn't be popular. They have other tricks to address Sound Blaster issues like clicks/pops besides filtering and there's one potentially useful inventory of them here, and I wonder if something like this envelope technique in response to #3 "brickwall audio" would be relevant/possible...

 

That gets to the next part, Woof's fixed crushers. I had an idea from reading those Sound Blaster issues that sounds getting interrupted instantly could cause clicks. I deleted "looping sounds don't interrupt each other" (lines 276-290 from s_sound.c) to maybe break the clicking crusher fix and sure enough, even when standing still the crushers at the start of DBP25 are back to clicking as the sounds cut off.

 

More exciting, whatever that did at the same time stopped other sounds from getting interrupted, and now I can spam use on a wall despite those clicking crushers, no problem! Of course, this makes the game sound weird, and it doesn't fix some other clicks that sound about the same as the interruptions, for instance at the end of DSPOPAIN.

 

https://vocaroo.com/13QYCelTfxRs - This is how the regular DSPOPAIN sounds in Woof, no interrupted sound involved and you can hear the click or "snap" at the end.

 

https://i.imgur.com/w6lZN3U.png - This is the spectrogram of DSPOPAIN, from what I understand the bright line at the far right is some kind of clipping or a click distortion or something that gets amplified when upsampled from 11khz to 44khz or whatever. The Doom sounds are full of stuff like that, and that's probably why "high resolution" audio packs like Per Kristian or Sound Bulb have been recommended to fix clicks, and why running Woof at 11025hz doesn't noticeably click.

 

Sure enough, I ran the de-clipper to fix just the bright line at the end of this sound and it sounds way better in Woof at 44.1khz, it doesn't really lose anything but the click. Of course, source ports won't include subjectively "restored" IWAD assets. But GZDoom doesn't click and doesn't have to do that either.

 

My guess is this is because GZDoom uses OpenAL, and instead of OpenAL maybe having a better resampler than SDL, it allows sounds to fade in or out a tiny bit and avoid playing those very stark and visible clicks or clipping or whatever it is at the beginning or end of the Doom sound effects. Many, but not all, sounds have the same kind of sudden clipping at the end. DSPODTH2 for example does not have that clipping and I don't remember ever hearing it click. There's an issue on the OpenAL Github page that got a feature like this added for a Silent Hill 2 PC port project. There's got to be more useful info in there too. That is just my assumption though, I don't know what GZDoom or OpenAL are really doing. Ideally those fades would be hard or impossible to notice and might also be part of how GZDoom avoids clicking crushers, I don't know.

 

So, I guess the question is whether fixing these clicks is worth all the effort and investigating, and if implementing this kind of subtle fading is possible with SDL or otherwise. As it is, you will probably get a click in your ear within the first minute of E1M1 in many ports. The Doom sounds will surely have all kinds of other clicks and clips and things in the middles somewhere, but the ones at the beginning or end of a sound really stand out in a bad way. Maybe there's a better and easier way to accomplish this, I am not knowledgeable enough. I think Woof has a lot of attention paid to having high quality and customizable sound, and if these clicks were fixed, there's really not much else to complain about. Change da world.

 

[rfomin]

18 hours ago, s4f3s3x said:

Very minor request: would it be possible to have ENDOOM displaying in nearest?

It doesn't look good with some window sizes/resolutions. I will try.

 

56 minutes ago, pantheon said:

TL;DR: Fix sound clicks by adding tiny fades in/out to sounds to dodge clipping in the original files and prevent interrupted sounds from clicking?

Interesting idea, thanks! There is a temptation to just switch to OpenAL if all else fails. OpenAL has a very different API.

[fabian]

I'm going to try the fade in/out approach, thanks for the idea! 

[fabian]

@pantheon Any chance you could test this branch?

https://github.com/fabiangreffrath/woof/pull/925

 

[pantheon]

On 3/3/2023 at 3:31 AM, fabian said:

@pantheon Any chance you could test this branch?

https://github.com/fabiangreffrath/woof/pull/925

 

 

No luck sadly :( I'm going to keep digging and see what else might come up. I feel like it's getting closer to something though... maybe OpenAL is also doing some kind of clipping removal or volume something? They talk about it here on the ZDoom forums a little bit.

 

Edit: Actually it DOES help with DSPOPAIN, but only if you're standing still!

 

 

 

Edited March 5, 2023 by pantheon

[Average]

@fabian, I realise you're busy with other stuff mentioned above but I was wondering if you've had any time to consider adding a 'splash' sound to animated liquid flats?

 

Just in case, I've attached Enjay's splash wad as a potential sound resource. :)

splash.zip

[liPillON]

4 hours ago, rfomin said:

It doesn't look good with some window sizes/resolutions. I will try.

 

what about always using integer scaling for ENDOOM, regardless of user's settings?

 

[fabian]

12 minutes ago, Delfino Furioso said:

what about always using integer scaling for ENDOOM, regardless of user's settings?

 

 

@rfomin let's just do this, please. It gets requested over and over again. 

[rfomin]

48 minutes ago, fabian said:

@rfomin let's just do this, please. It gets requested over and over again. 

It seems people are asking for different things. I think we want a fullscreen ENDOOM, but without linear scaling and with aspect ratio correction. I want to try downsampling (or bilinear sharpening) to solve the problem with non-square pixels.

[mikeday]

On-the-fly AI upscaling? ;-)

[Pixel Fiend]

It's a random statement but I want to express deep appreciation for how the fluidsynth midi is implemented in woof. I don't know if there's been any improvement or not (it's been a year since I last checked), but I remember being at large dissatisfied with the midis and now somehow any level I load makes me feel like at a midi concert, sounding perfectly as intended. Maybe the reverb effect goes a long way in feeling that way too. Well, suddenly I'm a full blown Doom fan once again.

Edited March 3, 2023 by Pixel Fiend

[fabian]

On 3/3/2023 at 2:10 PM, Average said:

@fabian, I realise you're busy with other stuff mentioned above but I was wondering if you've had any time to consider adding a 'splash' sound to animated liquid flats?

 

Do the sounds play instead of Doomguy's "oof" or additionally to it?

 

Edit: @Average I may have something for you: https://github.com/fabiangreffrath/woof/pull/931

 

Edited March 7, 2023 by fabian

[Average]

Thank you so much.  I've just got another question:  I've downloaded the x64 build but I still get the Oof! sound.  I looked through the config just incase there was a cvar but didn't see anything.  I then (noob move!) dragged and dropped the watermap WAD onto the EXE but it didn't do anything either.  Am I missing something in my excitement?

 

PS:  Thanks again for even entertaining the suggestion.  I really appreciate it. :)

[fabian]

It's just a pull request at the moment. I'm currently discussing it with @rfomin.

 

PS: While at it, one open question is whether to play the splash sound whenever the player steps down into a liquid sector, or only when he falls so deep that he would say "oof" otherwise? 

Edited March 7, 2023 by fabian

[Average]

Ahh, I see.  That'll explain it, then. :P

 

For me personally, I'd have the splash sound play instead of the Oof! when Doomguy falls from a height.  Otherwise I feel it'd be a bit strange to have him be all stealthy on hard surfaces and then makes lots of noise every time he encounters liquids, if that makes sense.

 

Also, if it's not too much to ask, it should be a menu option just in case there are any compatibility issues or strange edge cases.

[fabian]

31 minutes ago, Average said:

For me personally, I'd have the splash sound play instead of the Oof! when Doomguy falls from a height.  Otherwise I feel it'd be a bit strange to have him be all stealthy on hard surfaces and then makes lots of noise every time he encounters liquids, if that makes sense.

 

That makes sense, thank you for your input. 

 

31 minutes ago, Average said:

Also, if it's not too much to ask, it should be a menu option just in case there are any compatibility issues or strange edge cases.

 

The sounds will only be played if they are provided by the user. So, in this case, I guess they were loaded on purpose and don't require explicit confirmation. 

[liPillON]

quick heads-up about the recently merged PR implementing the color translation tables

 

something funny is happening with the keys' sprites: when using the boom hud, all six keys appears as (translated to) red

when using the statusbar (screensize<=7) the sprites seems unaffected

 

I've encountered this while trying out the latest github artifacts.

Latest unaffected autobuild: https://github.com/fabiangreffrath/woof/actions/runs/4297414912

First autobuild where the issue came up: https://github.com/fabiangreffrath/woof/actions/runs/4335957506

 

Edited March 7, 2023 by Delfino Furioso

[Classic SSG Enjoyer]

On 3/4/2020 at 7:42 PM, fabian said:

Hardware acceleration should be enabled by default in Woof. Now it would be interesting how both ports perform at fullscreen resolution. 

I dont play slaughtermaps, I dont want to play them in future, but I decided to test this 100,000 Revenants map, on latest version of Woof (Resolution 320X200) and DSDA Doom (OpenGL), (Resolution 320x200), just to test how both ports handle this map.

 

Once you teleport to the huge rev area, Woof gave me fps between 1 to 4. DSDA gave just a bit high upto fps from 3 to 6 fps. So, at least I confirmed that Woof is at par or at least, extremely close to DSDA Doom's OpenGL's Renderer, at least when performance is concerned.

Edited March 8, 2023 by Classic SSG Enjoyer

[reaction]

Is there any chance of -pistolstart being added as an arg? I know it's present in DSDA-Doom and since Woof! supports UMAPINFO I think it should be doable (not sure if how DSDA actually achieves the effect though).

[dististik]

48 minutes ago, reaction said:

Is there any chance of -pistolstart being added as an arg?

 

It's already in 10.5.1 at least, probably added sooner. There is also a settings menu option for it so you can more conveniently (at least imo) turn it on and off as you like.

Edited March 29, 2023 by dististik

[reaction]

19 minutes ago, dististik said:

 

It's already in 10.5.1 at least, probably added sooner. There is also a settings menu option for it so you can more conveniently (at least imo) turn it on and off as you like.

Fuck man, I even tried -pistolstart and checked the options menu, fuck I'm dumb.

[Average]

Is this something that could be useful for Woof! video output?

 

https://snowflakepowe.red/blog/announcing-librashader-0.1.0

 

I don't know what I'm talking about regarding coding and the like so feel free to point and laugh but I feel like CRT shaders in a Doom source-port would be glorious.  Woof! has a lovely look to it and I'd love to see it on a (albeit virtual) CRT.  Also, I can't think of another port that offers such a feature.

 

Anyway, just thought I'd throw this pie in the sky thought out there. :)

[rfomin]

Interesting project, thanks for the link.

 

Doom was originally built for PC CRT monitors, which don't have scanlines or a visible "pixel matrix," so perhaps a full-fledged Retroarch system is too much. Personally, I want to fix the "non-square pixels" problem with shaders, so a simpler system like in DosBox-X or DosBox-staging is more suitable. Anyway, I do not promise a quick implementation, but there are some plans.

[Average]

^

Oooh, sounds interesting.  :)