This is Woof! 14.3.0 (Mar 15, 2024)

[fabian]

Woof! 4.0.1

 

• Compatibility with PrBoom+ complevel 11 has been vastly improved:
  • Player bobbing calculation has been fixed (@rfomin).
  • Resetting of the doomednum feature for the MT_SCEPTRE and MT_BIBLE things has been removed, which would lead to these map things not being spawned if not in "beta emulation" mode (@rfomin).
  • The implementations of P_Move(), P_CreateBlockMap() and P_FindShortestTextureAround()/P_FindShortestUpperAround() have been modified to match the ones from Boom, which are unconditionally used in PrBoom+ (@rfomin).
  • More MBF code pointers have been disabled in Boom compatibility mode (@rfomin).
  • Compatibility defaults have been brought in line with PrBoom+:
    • Enable "Zombie players can exit levels".
    • Disable "Build stairs exactly the same way that Doom does".
    • Enable "Fix 3-key door works with only 2 keys".
• The padvalue typo in the REJECT buffer overflow emulation has been fixed (@rfomin).
• Data is now properly free()d in some functions in i_sound.c (@rfomin).
• A wrong function argument in MUSINFO logging has been fixed (@rfomin).
• A dummy entry has been added to the S_music[] array for the NUMMUSIC counter, fixing a crash when changing music from a MUSINFO track.

This release introduces some compromise regarding original MBF compatibility. Some code had to be unconditionally modified to achieve demo compatibility with PrBoom+ complevel 11 (which in turn means "MBF compatibility", ironically). To revert back to the original MBF code the WOOF_STRICT build parameter has been introduced, but is disabled by default.

 

https://github.com/fabiangreffrath/woof/releases/download/woof_4.0.1/Woof-4.0.1-win32.zip

 

Edited March 15, 2021 by fabian

[Eric Claus]

18 hours ago, fabian said:

Woof! 4.0.1

 

This release introduces some compromise regarding original MBF compatibility. Some code had to be unconditionally modified to achieve demo compatibility with PrBoom+ complevel 11 (which in turn means "MBF compatibility", ironically). To revert back to the original MBF code the WOOF_STRICT build parameter has been introduced, but is disabled by default.

 

https://github.com/fabiangreffrath/woof/releases/download/woof_4.0.1/Woof-4.0.1-win32.zip

 

 

This is interesting and I wonder where or how the compat changed over time.  I know you mentioned that maybe there was a bug in PrBoom somewhere from who knows when.  Sad that you had to compromise on this front as I know you were trying to be a bit more conservative with Woof but I guess in a way the complevel 11 has become the defacto MBF compat in a strange sort of way. Ironic as you said.  That said I am loving the improvements and it's nice to have both Crispy Doom and Woof on feature parity for the most part in many ways, and while the compromise is sad at least Woof will match the demos now and you do still have the build time option.  I am guessing it would have been too much of a pain to add PrBoom+ compat emulation or would it also just have been out of the scope of the port as I know you like to keep things a bit more conservative.  Just a point of curiosity thank you once again for your great work Fab.

[fabian]

4 hours ago, Eric Claus said:

complevel 11 has become the defacto MBF compat

 

Yep, that's pretty much it. 

 

Quote

I am guessing it would have been too much of a pain to add PrBoom+ compat emulation

 

Let's face it: Nobody cares for MBF.exe anymore. Apparently nobody has ever tried to run Eviternity demos in MBF.exe, else they would have seen that they desync - just as they did in Woof! until recently. I could have implemented a run-time option - and I seriously played the thought - but then I would have added an in-between compat level. We would have ended up with two concurrrent compatibility levels: one that the people would care about because it syncs with PrBoom+ and one that the people didn't care about because it would only sync with MBF.exe

 

I was never going for *bug-compatibility* with MBF. And in this special case, being demo incompatible with PrBoom+ complevel 11 would be considered a bug in Woof! - not PrBoom+.

[Ar_e_en]

On 3/15/2021 at 10:30 AM, fabian said:

• • Compatibility defaults have been brought in line with PrBoom+:
    • Enable "Zombie players can exit levels".

I remember playing Eviternity on an earlier version and wondering why the death exits wouldn't work. I did find the option that enables the death exits, but it's nice that now it's a default.

[Eric Claus]

17 hours ago, fabian said:

 

Yep, that's pretty much it. 

 

 

Let's face it: Nobody cares for MBF.exe anymore. Apparently nobody has ever tried to run Eviternity demos in MBF.exe, else they would have seen that they desync - just as they did in Woof! until recently. I could have implemented a run-time option - and I seriously played the thought - but then I would have added an in-between compat level. We would have ended up with two concurrrent compatibility levels: one that the people would care about because it syncs with PrBoom+ and one that the people didn't care about because it would only sync with MBF.exe

 

I was never going for *bug-compatibility* with MBF. And in this special case, being demo incompatible with PrBoom+ complevel 11 would be considered a bug in Woof! - not PrBoom+.

 

Thanks for indulging my curiosity and describing your thought process and goals! I find it interesting, especially seeing back to how ports have evolved and what that means with demo compatibility which is something I personally often look at in a source port.  I personally think it's a good change and Woof is probably going to end up my mainstay for Boom/MBF maps going forward now that your hard work has matured it so much and so quickly.  Honestly thinking back I agree that putting a flag in there would have just muddled things especially as you said nobody really cares about direct MBF.exe compat in the same way as say vanilla compat.  This is some good insight and I continue to look forward to the future of Woof!

[Catpho]

Hi, i've been using 4.0.1, and for some reason when i reload a save the music of the level stops. I have to use idmus to get the music playing again, but the behavior repeats every time i reload. Is this due to a setting?

[Eric Claus]

34 minutes ago, Catpho said:

Hi, i've been using 4.0.1, and for some reason when i reload a save the music of the level stops. I have to use idmus to get the music playing again, but the behavior repeats every time i reload. Is this due to a setting?

 

I was able to replicate this, loading a save caused the music to stop.  Running Woof on Windows 10.

[Ar_e_en]

2 hours ago, Catpho said:

Hi, i've been using 4.0.1, and for some reason when i reload a save the music of the level stops. I have to use idmus to get the music playing again, but the behavior repeats every time i reload. Is this due to a setting?

Trying to replicate this. Does it stop playing simply after a save and a reload? Does it happen after you relaunch the program and then load a save? Is the map you're loading into from a previous or different map? What wad are you using?

[fabian]

Confirmed, thanks. We are trying to load music from lump 0, which is PLAYPAL if I am not mistaken. The fix is trivial, will commit later today. 

[fabian]

Just out of curiosity: could any of you please tell me what is written to the terminal window when the music bug upon loading a savegame happens? This is probably only relevant to those running the port on Linux or in an MSYS2 window on Windows.

[OleBumma]

what's a good tool to edit the config? all I want is to set the backward motion to mouseb_backward (MB3) and simply editing the config in a text editor doesn't let me do it.

pressing the mouse button while in-game isn't letting me change the key for it.

 

thanks in advance!

Edited March 22, 2021 by OleBumma

[fabian]

1 hour ago, OleBumma said:

what's a good tool to edit the config? all I want is to set the backward motion to mouseb_backward (MB3) and simply editing the config in a text editor doesn't let me do it.

pressing the mouse button while in-game isn't letting me change the key for it.

 

There is currently no keybinding available for backward motion.

[OleBumma]

12 minutes ago, fabian said:

 

There is currently no keybinding available for backward motion.

yeah, figured out you've implemented mouse bindings for the "Use" and "Next/Prev Weap" functions only, which were needed.

would be cool to see it added someday, especially since the forward motion is bindable.

 

I'll be on the lookout to see how your project progresses.

[Ar_e_en]

3 hours ago, fabian said:

Just out of curiosity: could any of you please tell me what is written to the terminal window when the music bug upon loading a savegame happens? This is probably only relevant to those running the port on Linux or in an MSYS2 window on Windows.

I'd love to help, but I just can't recreate this bug on my Linux PC, the program works fine. When I reload a save from the same map - the music just keeps on playing. When I reload onto a different map - it spits out some errors, but It still works.

 

@Catpho is the one who reported this bug on their end. They most likely use Windows and are launching the program from the clickable executable. Maybe they could try and launch it from the windows command line? That might give some error messages on their end.

[fabian]

I remember I had the same bug in Crispy before. It seems that for some reasons, under certain conditions, lumpinfo[-1].name does indeed return a valid lump name. And if we have no MUSINFO music running, the current_item field of the musinfo struct is -1. Thus, an unrelated lump is saved as the one currently playing MUSINFO music. Ihave fixed this in GIT, but would like to be 100% that this is the same bug.

[Catpho]

Fwiw, i just found out that this is not consistent in every wad. I saved and load without any musical bugs in Antaresian Reliquary, but i get the problem every time in 50 Shades of Graytall. Hope this helps.

[Ar_e_en]

Tried "50 Shades of Graytall" - didn't experience the bug.

Considering that this only happens on specific wads as well as the fact that our Operating Systems are different - this could be a rather elusive bug.

 

That being said, Fabian might have fixed this bug in the current Git master version of Woof, you might just have to wait for 4.0.2 to see if it works now.

[fabian]

Woof! 4.0.2

• Add a config example for Vanilla automap colors (thanks @OpenRift412),
• Do not collapse leading slashes on Windows anymore in NormalizeSlashes() to recognize canonicalized Windows paths (@rfomin).
• Prevent running out of stack space in P_SetMobjState() (@rfomin).
• Only save MUSINFO music in savegames if it's actually playing.
• Keep the comp_3keydoor compatibility flag out of the comp[] array to prevent demo header mismatch with PrBoom+

https://github.com/fabiangreffrath/woof/releases/download/woof_4.0.2/Woof-4.0.2-win32.zip

[Catpho]

It works now. Thank you :)

[roadworx]

hey, i just wanted to say thank you for creating and maintaining woof. it's by far the best source port i've ever used in terms of filling my specific personal preferences, and i really can't wait to see how it develops in the future <3

[Eric Claus]

5 hours ago, roadworx said:

hey, i just wanted to say thank you for creating and maintaining woof. it's by far the best source port i've ever used in terms of filling my specific personal preferences, and i really can't wait to see how it develops in the future <3

 

Hey I remember when I recommended Woof to you.  Glad to see it filled your needs! One of us! One of us!

[Pixel Fiend]

This source port for the win... oh my god. Crispy Boom is what I need. Better for me than Prboom+ in terms of graphics, gameplay, and somehow even... midi? Though the main question is, can it ever match the performance of PrBoom+?

 

On 3/23/2021 at 9:20 AM, fabian said:

Add a config example for Vanilla automap colors

Where can I find this, please?

Edited April 4, 2021 by <<Rewind

[Eric Claus]

1 hour ago, <<Rewind said:

This source port for the win... oh my god. Crispy Boom is what I need. Better for me than Prboom+ in terms of graphics, gameplay, and somehow even... midi? Though the main question is, can it ever match the performance of PrBoom+?

 

Where can I find this, please?

 

Honestly I have not done any benchmarks, but I have never noticed any sort of performance problems with either port honestly.  Though it's hard for me to compare as running without Vsync on some ports tends to cause warping and tearing for me in widescreen modes with Doom rendering but is completely smooth with vsync on.

[Eric Claus]

Well just went ahead and fired up Sunlust Map 18 Mu Cephei on both DSDA Doom and Woof and got an interesting result.  I didn't notice any frame hitches at all (I assume my DSDA is in software mode) between Woof and DSDA.  The interesting part is DSDA seems to use my CPU less, but over double the memory, and Wood uses the CPU a bit more, but less memory...This isn't the most amazing of tests but the result is a bit different than I expected.

[fabian]

On 3/22/2021 at 1:52 PM, OleBumma said:

would be cool to see it added someday, especially since the forward motion is bindable.

 

There are now mouse button bindings available for backward motion and turning left/right.

 

On 4/5/2021 at 12:16 AM, <<Rewind said:

Where can I find this, please?

 

Currently in the sources only, but it will get installed into the docs/ directory from the next release on.

 

https://github.com/fabiangreffrath/woof/blob/master/docs/mapcolors_vanilla.cfg

[Pixel Fiend]

Is there a chance for such features as brightmaps and blood fix?

[BlueThunder]

7 hours ago, <<Rewind said:

Is there a chance for such features as brightmaps and blood fix?

The blood fix would be nice to match crispy

[Pixel Fiend]

 

The automap is also too small

[fabian]

6 minutes ago, <<Rewind said:

The automap is also too small

 

Compared to what?

[Pixel Fiend]

The second screenshot is how it loads in Chocolate Doom or Crispy Doom.