This is Woof! 14.5.0 (Apr 30, 2024)

[Classic SSG Enjoyer]

2 hours ago, fabian said:

One didn't have to do with the other. Strict mode has absolutely nothing to do with demo compatibility - as has been told to you before.

Yeah, I remember you told me on Chocolate Doom Discord.

 

[Classic SSG Enjoyer]

2 hours ago, fabian said:

It is just there to avoid accidently using features which would be considered against the rules of the speed running community when recording demos.  

Yeah, even this you told me. But I forgot due to my weak memory.

 

Ah, got my answer! Thanks ;)

[maxmanium]

I've noticed that sometimes entering a new level, it continues to play the D_READ_M or D_DM2INT.

 

Edit: Actually, seems to happen every time for me.

 

Edit 2: Might have something to do with the IDMUS cheat? I don't remember using it on this save tho.

Edited May 10, 2023 by maxmanium

[rfomin]

5 hours ago, maxmanium said:

I've noticed that sometimes entering a new level, it continues to play the D_READ_M or D_DM2INT.

 

Edit: Actually, seems to happen every time for me.

 

Edit 2: Might have something to do with the IDMUS cheat? I don't remember using it on this save tho.

I can't replicate it yet. Can you post this save? And what WAD/map?

[Trov]

On 5/5/2023 at 8:30 PM, rfomin said:

@Tarvis @mikeday Thanks for the investigation, this will be fixed.

I guess while we're at it, windowed mode also uses the monitor's resolution for 'auto' widescreen aspect ratio. Could it be altered so that the 'auto' widescreen setting matches the window size instead of monitor size when the game is windowed?

[maxmanium]

7 hours ago, rfomin said:

I can't replicate it yet. Can you post this save? And what WAD/map?

 

Wad is Headless Chicken:

 

Haven't looked in the wad itself so not sure if it is specific to it.

 

Save: woofsav2.zip

 

EDIT: I had a slightly older version so the loaded save looks a bit weird but should still work. It's right next to the exit.

Edited May 11, 2023 by maxmanium

[rfomin]

11 hours ago, Tarvis said:

I guess while we're at it, windowed mode also uses the monitor's resolution for 'auto' widescreen aspect ratio. Could it be altered so that the 'auto' widescreen setting matches the window size instead of monitor size when the game is windowed?

Then we will have to change the internal resolution every time the window is resized. Works fine on Windows, not sure about other platforms. @fabianshould we do it?

 

7 hours ago, maxmanium said:

I had a slightly older version so the loaded save looks a bit weird but should still work. It's right next to the exit.

Save works fine, thanks. I confirm, the problem is related to the recent MUSINFO changes. This will be fixed in the next release.

[fabian]

1 hour ago, rfomin said:

Then we will have to change the internal resolution every time the window is resized. Works fine on Windows, not sure about other platforms. @fabianshould we do it?

 

Let's do exactly what Crispy does. 

 

1 hour ago, rfomin said:

Save works fine, thanks. I confirm, the problem is related to the recent MUSINFO changes. This will be fixed in the next release.

 

Thanks for taking care of this!

[gendlin]

Thanks for exclusive fullscreen ❤️ I had a feeling the compositor was robbing me of frames but didn't know how to prove it

[Trov]

Is complevel supposed to affect UMAPINFO endgames?

 

With -complevel 2 (or 3 or 4) endgames dont seem to work right if they aren't on map30.

 

For instance on a map (let's say MAP10) with this UMAPINFO block

map MAP10
{
	endgame = true
	intertext = "text here"
	endcast = true
}

If you fire or press use when it reaches the cast roll, instead of going through the cast roll it instead goes to the next map. There should be no next map since it's an endgame.

 

Using endpic instead of endcast instead also has odd behavior, if you fire or press use it will do a screen wipe to the same image. It also buffers multiple clicks so it will keep doing wipes over and over while you go through the menu.

 

Behaves as expected with -complevel 9 and up.

 

These issues seem to be inherited from DSDA-Doom which have the same behavior.

[rfomin]

Yes, there are problems with the UMAPINFO's endgame, endcast, and intertext fields. This is from the original implementation in PrBoom+, which was taken by Woof and inherited by DSDA-Doom, and we can't change it due to demo compatibility. Although I doubt anyone is using this as it is broken. Maybe we can just fix it what do you think @dsda-dev?

Edited May 14, 2023 by rfomin

[Trov]

I know it also makes it skip intertexts with one button rather than printing the rest to the screen, but keeping that makes sense for demo reasons.

However are there really any demos out there that insist on playing past the end of a WAD to play the remainder of stock doom 2 levels?

 

 

One goofy solution would be to only break it if recording/playing a demo.

Edited May 14, 2023 by Tarvis

[dsda-dev]

We can probably just fix this. As you said, the game basically goes into invalid / undefined behaviour that is outside the bounds of the pwad anyway.

[fabian]

Woof! 11.1.0 is released on May 17, 2023.

 

A complete list of new features, improvements and bug fixes can be found on the release page:

 

https://github.com/fabiangreffrath/woof/releases/latest

 

Binaries for Windows are available here:

 

https://github.com/fabiangreffrath/woof/releases/download/woof_11.1.0/Woof-11.1.0-win32.zip

https://github.com/fabiangreffrath/woof/releases/download/woof_11.1.0/Woof-11.1.0-win64.zip

 

 

Have a lot of fun!

- Fabian

[Jack9955]

Why can't I change the resolution while in exclusive fullscreen? It stays in 1920x1080. I want to try 640x480.

[rfomin]

34 minutes ago, Jack9955 said:

Why can't I change the resolution while in exclusive fullscreen? It stays in 1920x1080. I want to try 640x480.

You can change the desktop resolution to 640x480. I don't recommend this, I think there's no point in changing the fullscreen resolution unless you're using a CRT monitor. Woof's internal resolution is 640x480 in non-widescreen mode, which scaled to desktop resolution.

[Jack9955]

11 minutes ago, rfomin said:

You can change the desktop resolution to 640x480. I don't recommend this, I think there's no point in changing the fullscreen resolution unless you're using a CRT monitor. Woof's internal resolution is 640x480 in non-widescreen mode, which scaled to desktop resolution.

Before 11.0.0, I could change the exclusive fullscreen resolution.

[rfomin]

Just now, Jack9955 said:

Before 11.0.0, I could change the exclusive fullscreen resolution.

Yes, I removed this because now we can switch to exclusive fullscreen mode in the menu on the fly, and if we change the fullscreen resolution, it sometimes glitches on my Windows 10 system. We can restore these configuration settings, but why do you need it? I thought native resolution is always preferable.

[Jack9955]

9 minutes ago, rfomin said:

Yes, I removed this because now we can switch to exclusive fullscreen mode in the menu on the fly, and if we change the fullscreen resolution, it sometimes glitches on my Windows 10 system. We can restore these configuration settings, but why do you need it? I thought native resolution is always preferable.

 

I feel like 640x480 is the right resolution for Doom (After 320x240)

[rfomin]

Just now, Jack9955 said:

I feel like 640x480 is the right resolution for Doom (After 320x240)

Woof is always in 640x480 (or 320x240), it simply scales to whatever resolution your desktop has. There is no point in changing the actual fullscreen resolution to a very low 640x480 as modern Windows doesn't like that (at least on my systems). Visually, it will look the same anyway.

[liPillON]

something strange happened with dehacked in my 11.1.0 setup

weapons animations for mods like BlackOps and VanillaSmooth (both CL2 dehextra) and MiniCharge (CL11 dehacked) broke

 

this was after replacing the 11.0.0 binaries with those from the latest release, keeping the config file and the autoload folder intact

the previous woof releases did not exhibit this behaviour

 

I tried using the 11.1 binaries after removing the autoload folder, and all mods started working as intended again

 

Turns out I was autoloading the dehacked patch from the Sprite Fixing Project and removing it was the solution

Why previous releases were unaffected by this, though?

 

Edited May 17, 2023 by liPillON

[liPillON]

actually, i take that back... 

it seems to happen completely at random even without anything in the autoload folder..

 

once it happens, mods stay broken until i delete the autoload folder and/or the tranmap.dat file

 

here a simple & clean test environment woof-11.1-win64-deh-test-env.7z - just drop the doom2 iwad in it

I'm running it on win11 x64 enterprise

 

 

 

Edited May 17, 2023 by liPillON

[Alaux]

1 hour ago, liPillON said:

something strange happened with dehacked in my 11.1.0 setup

weapons animations for mods like BlackOps and VanillaSmooth (both CL2 dehextra) and MiniCharge (CL11 dehacked) broke

I merged Woof 11.1's changes into Nugget Doom right after the former was released, and I indeed got the issue in Nugget, although I wasn't able to reproduce it in Woof.

 

What breaks for me specifically (which I guess is your case too) is loading of DeHackEd patches from within WADs. According to console output the patches are loaded, but they've no effect in-game. I was able to fix it by either removing at least one out of five files in my doom2.wad autoload folder, or by actually providing DOOM2.WAD in the port's folder (up until then it was instead being loaded from my DOOMWADPATH, like the rest of IWADs). I had issues with drag & drop previously that seemed to be caused by similar reasons, so I just shrugged this off as a problem with my system. I'm on Win7, by the way

[rfomin]

@liPillON @Alaux This bug is caused by DEH parser changes, I think your autoload and path settings are fine. Thanks for the report, we'll fix it.

[liPillON]

good to know!

 

I would have submitted an issue on github myself, but I was not able to reproduce the bug consistently..

 

I'm looking forward to 11.1.1 ;)

 

[OpenRift]

So I saw the new update and this one note certainly got my attention.

Quote

Add MIDI compatibility levels. winmm_complevel config option:
0: Vanilla (Emulates DMX MPU-401 mode)
1: Standard (Emulates MS GS Synth) (Default)
2: Full (Send everything to device, including SysEx)

Does this mean that Woof can fully emulate the limitations of DMX and MUS format as well? If so that's actually really great, and I do hope we see something like that implemented into Chocolate Doom.

[fabian]

Woof! 11.1.1 is released on May 17, 2023.

 

A complete list of new features, improvements and bug fixes can be found on the release page:

 

https://github.com/fabiangreffrath/woof/releases/latest

 

Binaries for Windows are available here:

 

https://github.com/fabiangreffrath/woof/releases/download/woof_11.1.1/Woof-11.1.1-win32.zip

https://github.com/fabiangreffrath/woof/releases/download/woof_11.1.1/Woof-11.1.1-win64.zip

 

 

Have a lot of fun!

- Fabian

[ceski]

2 hours ago, OpenRift said:

So I saw the new update and this one note certainly got my attention.

Does this mean that Woof can fully emulate the limitations of DMX and MUS format as well? If so that's actually really great, and I do hope we see something like that implemented into Chocolate Doom.

 

I recently added it to Chocolate and Fabian merged it into Crispy. Keep in mind it's a compatibility setting. It doesn't use DMX's broken volume slider, broken drum channel volume, broken bank select support, or broken MIDI looping (the long pause at an end of a MIDI file due to MUS conversion). If you're curious about the technical details I documented the compatibility levels here.

[Lila Feuer]

On 5/7/2023 at 3:16 AM, rfomin said:

It could also crash in previous versions. Here we decided to match the behavior with Choco/PrBoom+/DSDA-Doom, see: https://github.com/fabiangreffrath/woof/issues/917

 

Does that mean it's just "broken" now when running in these ports? I say broken in quotations because it sounds more like a map error to me.

[OpenRift]

1 minute ago, ceski said:

 

I recently added it to Chocolate and Fabian merged it into Crispy. Keep in mind it's a compatibility setting. It doesn't use DMX's broken volume slider, broken drum channel volume, broken bank select support, or broken MIDI looping (the long pause at an end of a MIDI file due to MUS conversion). If you're curious about the technical details I documented the compatibility levels here.

I see. I was more referring to the limitations mentioned on the MUS format wiki page. Stuff like being limited to 9 channels (8 instruments + 1 drums) as well as the conversion size limit of 64 Kilobytes. In vanilla, if a MIDI lump can't be successfully converted to MUS, it will just play silence. It's a very common oversight that a lot of mappers make when putting MIDIs on their maps because no source port currently emulates those limits, including Chocolate Doom.