This is Woof! 12.0.2 (Dec 13, 2023)

Just now, VGA said:

All demos that use the 3-key bug should be banished from space and time.

I agree, but this isn't one of those cases. It's a Boom demo so it works as intended.

Oh, has Woof kept the 3-key bug intact?

3 minutes ago, VGA said:

Oh, has Woof kept the 3-key bug intact?

There's a compat flag for it, but it is ignored in demos.

Oh, indeed, I need to enable the fix for Boom but keep it disabled for MBF demos. Thanks for the reports, people, this is really helpful! 

Ran a quick test.

Some minor variations with sound blocks and demo syncing, but otherwise it seems to

work pretty well. Nice to have a exe, that you can drag and drop pwads onto.

1 hour ago, Urthar said:

Nice to have a exe, that you can drag and drop pwads onto.

This is a ... new thing for you? :D

6 hours ago, Urthar said:

Some minor variations with sound blocks and demo syncing,

What does this mean, could you please be a bit more specific? 

8 hours ago, VGA said:

This is a ... new thing for you? :D

You'll laugh, but I actually wrote out a batch file at first because that's the behaviour I would expect from a Chocolate Doom style port.

4 hours ago, fabian said:

What does this mean, could you please be a bit more specific? 

Most sound activations seemed to occur as expected, including any number of teleport ambushes using a joined sector to transmit sound. In certain cases however, monsters I would expect to have been woken in the normal course of play remained dormant until line of sight was established. Since I was only playing casually rather than testing and documenting, I can't be more specfic, but something felt off.

Included demos, recorded in PrBoom+ complevel 11 desync'ed (but that happens in Eternity Engine too.)

39 minutes ago, Urthar said:

You'll laugh, but I actually wrote out a batch file at first because that's the behaviour I would expect from a Chocolate Doom style port.

I have added support for drag-and-drop to Choco some time ago, so the next release will have it and Crispy already has it for some releases. The same implementation is now used in Woof!:

https://github.com/chocolate-doom/chocolate-doom/commit/0abcb12fbbf199fa561da03794326e242b94018d

Quote

Included demos, recorded in PrBoom+ complevel 11 desync'ed (but that happens in Eternity Engine too.)

Well, this is MBF. So, if PrBoom+ created an MBF demo and it desyncs this could just as well be a bug in PrBoom+ o_O. Anyway, would you please tell me which WAD and demo that is?

Dimension of the Boomed DOTB_RC3.WAD includes 3 demos for sourceports that playback demos at the Menu screen. MAP02 demo seemed fine, MAP08 desync'ed towards the end, and the MAP01 demo desync'ed near the start.

(Edit: After a quick look, the MAP01 demo appears to desync in PrBoom+ itself, so who knows what happened there.)

17 hours ago, maxmanium said:

I don't know if this is relevant, but demos for MAP33 of sf2012_final.wad also desync since it has a three-key door.

These demos do not desync anymore, and they do not crash in the intermission screen anymore with the newest state in GIT.

1 hour ago, Urthar said:

Dimension of the Boomed DOTB_RC3.WAD includes 3 demos for sourceports that playback demos at the Menu screen. MAP02 demo seemed fine, MAP08 desync'ed towards the end, and the MAP01 demo desync'ed near the start.

Unfortunately, this WAD doesn't load in WinMBF ("R_GenerateLookup: Column without a patch in texture ..." for 123 textures), so it's impossible to know if the desync occurs there already (which I believe).

17 hours ago, VGA said:

Oh, has Woof kept the 3-key bug intact?

Yes, of course, else regular MBF demo would desync!

@fabian, how the hell do you build this on Windows? CMake outputs errors with MSYS2 regarding CMakeLists.txt.

So far, I would say that this source port is a step in the right direction in terms of preserving the history of MBF as well as bringing it to a modern audience, and I have found no glaring bugs during my short playtime. However, I have found that the sound volume is tied to the music volume (and the music volume is fucking loud) so whenever I try to turn down the music volume, the sound volume lowers as well. This is extremely annoying and I hope there is a way that this can be fixed soon. Otherwise, this source port is pretty amazing! :D

20 hours ago, maxmanium said:

@fabian, how the hell do you build this on Windows? CMake outputs errors with MSYS2 regarding CMakeLists.txt.

Since you didn't post the error that you encountered, it is hard to tell what went wrong. Generally, I would try to do what the ./travis,sh script does:

mkdir build && cd build
cmake -G "Unix Makefiles" ..
make

20 hours ago, TheWolfman00001 said:

So far, I would say that this source port is a step in the right direction

Thank you!

20 hours ago, TheWolfman00001 said:

However, I have found that the sound volume is tied to the music volume (and the music volume is fucking loud) so whenever I try to turn down the music volume, the sound volume lowers as well. This is extremely annoying and I hope there is a way that this can be fixed soon. Otherwise, this source port is pretty amazing! :D

This is a well known bug, especially with SDL-based games. For whatever reason, Windows doesn't allow a single process to change its music and sound effects volume separately anymore. Some source ports help themselves by introducing another process (midiproc) which takes the part of MIDI playback, but I am currently not working on that.

1 hour ago, fabian said:

This is a well known bug, especially with SDL-based games. For whatever reason, Windows doesn't allow a single process to change its music and sound effects volume separately anymore. Some source ports help themselves by introducing another process (midiproc) which takes the part of MIDI playback, but I am currently not working on that.

Yea, this originally started happening with Vista, when the sound system saw some changes but that also borked some parts of it that never got fixed - and by the looks of it, MS has no interest in doing that either.

There's more ways to work around it I think, the easiest is to provide a separate .exe handling the music, and another one from what I've been reading is to use some hack to force Windows into giving the user the volume control. A separate .exe is probably the best option since it doesn't well, involve hacks :v .

The best way to deal with MIDI is to use an OS independent software synth.

BTW, ZDoom's MIDI player can change volume of the Windows synth independently of sound effects by altering the volume of the single notes.

2 minutes ago, Graf Zahl said:

The best way to deal with MIDI is to use an OS independent software synth.

Not all ports have that, do they :p .

How does Crispy Doom solve it? I don't see a separate process.

39 minutes ago, VGA said:

How does Crispy Doom solve it? I don't see a separate process.

There should be a separate crispy-midiproc.exe executable in the zip distribution.  It's great when it works, but it's also been a source of hard-to-diagnose problems in the past, so I don't blame anybody for not necessarily wanting to take the plunge on it.

14 hours ago, fabian said:

 

Since you didn't post the error that you encountered, it is hard to tell what went wrong. Generally, I would try to do what the ./travis,sh script does:

 

mkdir build && cd build
cmake -G "Unix Makefiles" ..
make

 

Usually with MSYS2 I put in "MSYS Makefiles" instead of "Unix Makefiles".

14 hours ago, fabian said:

This is a well known bug, especially with SDL-based games. For whatever reason, Windows doesn't allow a single process to change its music and sound effects volume separately anymore. Some source ports help themselves by introducing another process (midiproc) which takes the part of MIDI playback, but I am currently not working on that.

My usual workaround is SDL's built-in timidity support. You'll need to grab a compatible patch set. I prefer 8mbgmpat for this purpose, though eawpats and the stock GUS patches are also possible options. Place the folder wherever you want, copy the timidity.cfg file from the folder to your (in this case) Woof directory, and then change the "dir" line in the timidity.cfg file to match the location of the patches.

If it worked correctly, the volume of the music can then be set separately. It'll sound different than the Microsoft GS synth, sure, but at least it works properly now due to no longer using Windows' broken MIDI system.
Of course, when and if Woof gets a working midiproc solution, the SDL Timidity workaround will no longer be necessary.

5 hours ago, AlexMax said:

It's great when it works, but it's also been a source of hard-to-diagnose problems in the past, so I don't blame anybody for not necessarily wanting to take the plunge on it.

This. And virus scanners regularly identify it as malware. Yay, Windows!

I have just released Woof! 1.1.0:

• The port is now more forgiving when a flat lump cannot be found and renders the sky texture instead.
• Mouse acceleration has been entirely disabled.
• The rendering of flats has been improved (visplanes with the same flats now match up far better than before and the distortion of flats towards the right of the screen has been fixed).
• Some nasty rendering and automap glitches have been fixed which became apparent especially in extremely huge levels (including the "long wall wobble").
• Demo compatiblity with Boom 2.02 has been improved (including the 3-key door bug fix).
• Maps without level name graphics do not crash during the intermission screen anymore.
• Vast overhaul of the CMake build system (@AlexMax).
• Screenshots are now saved in PNG format using the SDL2_Image library.

https://github.com/fabiangreffrath/woof/releases/download/woof_1.1.0/Woof-1.1.0-win32.zip

21 hours ago, seed said:

 

Not all ports have that, do they :p .

No, but they could ;)

@fabian Have you considered looking into the improvements of the unofficial MBF 2.04 release? I am just leaving this here as it might be relevant to Woof.

Nope, never cared. Are there any specific features that you'd like to see in Woof?

This isn't in the aforementioned 2.04 release, but it'd be cool if Woof supported uncapped framerate. I'm not sure if this falls within the design philosophy though. I only ask because it looks really weird to have 640x480 resolution at 35 fps, in my opinion.

EDIT: Also, mouse scrollwheel zooming for the automap would be nice.

18 hours ago, maxmanium said:

This isn't in the aforementioned 2.04 release, but it'd be cool if Woof supported uncapped framerate. I'm not sure if this falls within the design philosophy though. I only ask because it looks really weird to have 640x480 resolution at 35 fps, in my opinion.

Nope, sorry, this is not on the agenda - ar least not currently. AlexMax already offered to add an implementation but I declined. Frame interpolation means too many code changes in too many places all over the code - that's also the main reason against the WiggleFix. Also, there is no canonical reference implementation - what looks good in Crispy might yield unusable results with a different code base.

It's just too much hackery. While this is okay for Crispy - which I consider my own code - I am a lot more reluctant in this project because I still consider this as Lee's code. And changes like these are just too "un-MBF".

Quote

EDIT: Also, mouse scrollwheel zooming for the automap would be nice.

This is a bit more probable, I'll look into it. 

18 hours ago, fabian said:

Nope, never cared. Are there any specific features that you'd like to see in Woof?

Well, Woof is a conservative port by heart, so features should be accordingly i feel. But it can be a good test port too because of it.

• Parameters "-stdvid" and "-bestvid" for benchmarking under comparable game settings.

These seem to be nothing more than a bunch of default settings:

https://github.com/Sakitoshi/mbf_sigil/blob/67faf637cfdc812eb8fa7fc218a2a34f60aa851b/m_misc.c#L1962

However, benchmark results achieved with these settings are not comparable to a SDL-based port anyway, thinking of how differently rendering features like e.g. vsync are implemented.