This is Woof! 14.5.0 (Apr 30, 2024)

[Eric Claus]

19 hours ago, fabian said:

 

It's astonishing to see how many compatiblity issues MBF has with respect to Boom. Anyway, they are currently worked on and Boom compatibility should be close to 100% for the next release. However, during the course of fixing these, we also found a couple compatbility issues in PrBoom+ with the complevels it is supposed to emulate. For example, the `0` in the lines that have the "//jff 8/14/98 texture 0 is a placeholder" comment should actually be `1` in Boom (they are `0` only in MBF, though):

https://github.com/coelckers/prboom-plus/blob/master/prboom2/src/p_spec.c#L694

 

Very strange, as you said MBF is a superset of Boom and thus this shouldn't even be something that pops up at all and I can understand your frustration.  My first thought was maybe something with the map itself and not with Woof and figured that it did something nonstandard that worked in other ports but not Woof for whatever strange reason.  Thank you for the update I hope I have not been frustrating just reporting things in case an issue is undiscovered as I like seeing Woof progressing.

[fabian]

This isn't frustrating at all, it's more fascinating to see how subtle bugs and glitches have evolved through the genealogy of source ports. I guess at one point Lee considered his own implementations superior to all former work (especially Boom) and just decided to give up on compatibility at all. And even Boom has never been developed with full Vanilla demo compatibility (as we know it today) in mind. I guess, back then it was considered a given fact that you just cannot preserve demo compatibility between different builds on different platforms. This was before people started to implement crazy stuff like overflow emulations, etc.

 

One thing that bothers me, though, is that there are many Eviternity demos recorded with PrBoom+ complevel 11 that desync in Woof - even in version 0.9 which was really just WinMBF converted to SDL2 without any further modifications. So there is another subtle bug slumbering in PrBoom+ that breaks demo compatibility with MBF.

 

Again, please report issues as you find them.

[Eric Claus]

16 hours ago, fabian said:

This isn't frustrating at all, it's more fascinating to see how subtle bugs and glitches have evolved through the genealogy of source ports. I guess at one point Lee considered his own implementations superior to all former work (especially Boom) and just decided to give up on compatibility at all. And even Boom has never been developed with full Vanilla demo compatibility (as we know it today) in mind. I guess, back then it was considered a given fact that you just cannot preserve demo compatibility between different builds on different platforms. This was before people started to implement crazy stuff like overflow emulations, etc.

 

One thing that bothers me, though, is that there are many Eviternity demos recorded with PrBoom+ complevel 11 that desync in Woof - even in version 0.9 which was really just WinMBF converted to SDL2 without any further modifications. So there is another subtle bug slumbering in PrBoom+ that breaks demo compatibility with MBF.

 

Again, please report issues as you find them.

 

Ah that makes sense, and I find it a bit interesting as well now that I have encountered it.  I will continue to submit anything that looks off and appreciate your hard work.

[omx32x]

mouse seens kinda slow i dont know if that was in the original mbf but if you could make the slider go even faster it would be really nice

[Ar_e_en]

So, I tried playing Ancient Aliens and the game crashes on the first map.
After getting the pipe and going through the wolf warp - I reach the Cyberdemon part, the music changes from the normal musical track to the midi track, the midi track plays for a few seconds and then it crashes. I also briefly checked the other maps and they seem to be fine, so I think there is a problem with the music changing feature. 

[Eric Claus]

6 hours ago, Ar_e_en said:

So, I tried playing Ancient Aliens and the game crashes on the first map.
After getting the pipe and going through the wolf warp - I reach the Cyberdemon part, the music changes from the normal musical track to the midi track, the midi track plays for a few seconds and then it crashes. I also briefly checked the other maps and they seem to be fine, so I think there is a problem with the music changing feature. 

 

Was trying to replicate this and had...no music.  That is weird.

[AnotherGrunt]

On 2/17/2021 at 2:28 PM, Ar_e_en said:

I don't think it has, but it would be nice to have when testing levels.

 

I had to add so called "Pacifist mode" in my MBF port. Just because of Eviternity (monster count attacking hundreds if not thousands in some levels would choke poor old DOS machine):

//m_cheat.c:
static void cheat_pacifist()
{
  extern int always_reject;           //CheckSight always false
  plyr->message = (always_reject = !always_reject) ? "Pacifist mode On" :
    "Pacifist mode Off";
}

//m_sight.c:
boolean P_CheckSight(mobj_t *t1, mobj_t *t2)
{
  const sector_t *s1, *s2;
  int pnum;
  los_t los;

  if (always_reject)
    return false;
  
  #ifdef V12C
  if (v12_compat)

Monsters will be loaded into level, but they won't attack unless provoked. And most importantly it disables entire sight-checking system.

[Ar_e_en]

2 hours ago, Eric Claus said:

 

Was trying to replicate this and had...no music.  That is weird.

Was there no music in general or did only one of the tracks play? If the midi track didn't play and your PC runs on Linux - you need to add an Environment Variable to ".bashrc" that sets the default sf2 soundfont for SDL2 applications that use Fluidsynth (I had this problem when I switched to Manjaro) - go check the Arch Wiki article on Fluidsynth - it may help.

 

If it doesn't play at all and you use Linux - then that's pretty weird that we experience different problems on the same map. Did all the other maps play the music?

If you use Windows - then I can't help, sorry.

[Eric Claus]

1 minute ago, Ar_e_en said:

Was there no music in general or did only one of the tracks play? If the midi track didn't play and your PC runs on Linux - you need to add an Environment Variable to ".bashrc" that sets the default sf2 soundfont for SDL2 applications that use Fluidsynth (I had this problem when I switched to Manjaro) - go check the Arch Wiki article on Fluidsynth - it may help.

 

If it doesn't play at all and you use Linux - then that's pretty weird that we experience different problems on the same map. Did all the other maps play the music?

If you use Windows - then I can't help, sorry.

 

On Windows so not sure what is going on there.  Other maps played the music fine.

[Ar_e_en]

2 minutes ago, Eric Claus said:

 

On Windows so not sure what is going on there.  Other maps played the music fine.

Maybe Woof 3.1.0 just has different bugs on different operating systems?

Also, which track didn't play on the first map - the non-midi, the midi or both?  

[Eric Claus]

Just now, Ar_e_en said:

Maybe Woof 3.1.0 just has different bugs on different operating systems?

Also, which track didn't play on the first map - the non-midi, the midi or both?  

 

Neither played. Just no music at all, strange.

[fabian]

Are you guys running the 3.1 release or a dev snapshot? Because, the release doesn't support MUSINFO, but the dev version does. 

[Eric Claus]

2 minutes ago, fabian said:

Are you guys running the 3.1 release or a dev snapshot? Because, the release doesn't support MUSINFO, but the dev version does. 

 

3.1 release, so that would be the explanation then.  Thank you fab.

[Ar_e_en]

3.1.0 Linux version from the AUR here. Guess that explains it then. Thanks fab! 

Edited March 7, 2021 by Ar_e_en

[fabian]

Woof! 4.0.0

 

• The -fast and -respawn options are now properly reloaded from savegames.
• PNG screenshots are now exact reproductions of the actual game screen.
• Framebuffer overflows are now prevented in V_DrawPatchGeneral() and V_CopyRect().
• The bmp2c.c tool now builds with MSVC build (@rfomin).
• A workaround for the SDL 2.0.14 Alt-Tab bug on Windows has been introduced (@rfomin).
• A woof-midiproc.exe has been ported over from Crispy Doom, allowing to set SFX and music volume separately on Windows (@rfomin).
• The SPECHITS overflow emulation has been ported over from Chocolate Doom / PrBoom+, allowing for some more obscure Vanilla demos to keep sync.
• The "IDKFA" cheat string has been externalized, allowing it to be replaced by DEHACKED.
• The widescreen rendering mode has been ported over from Crispy Doom with proper support for the widescreen assets found e.g. in the Unity version of Doom (@rfomin).
• MIDI playback on big-endian systems has been fixed (@BeWorld2018).
• The "HI_START"/"HI_END" namespace has been introduced to avoid conflicts with high-resolution textures (@rfomin).
• The option to show the "A secret is revealed!" message has been added (@rfomin).
• The window geometry and display index settings are now saved across restarts (@rfomin).
• The -pistolstart command line option has been added (@rfomin).
• Support for 16-bit WAV sound lumps has been added (@rfomin).
• Support for the "MUSINFO" lump has been added (@rfomin).
• Demo compatibility with Boom 2.02 has been vastly improved:
  • MBF codepointers are now disabled during Boom demo playback (@rfomin).
  • The P_FindShortestTextureAround() function has been fixed (@rfomin).
  • Boom's friction code has been restored (@rfomin).
  • Boom's BLOCKMAP generation code has been integrated (@rfomin).
• Sprite lumps smaller than 8 bytes are now ignored (@rfomin).
• Empty music lumps (i.e. with zero length) are now properly handled (@rfomin).
• The weapon attack alignment implementation has been brought in line with Crispy Doom.
• The "no fog on spawn west" Vanilla Doom bug is now properly emulated (@rfomin).
• Switches definitions referencing unknown texture names are now ignored instead of exiting (@rfomin).
• A crash has been fixed when reading out joystick button states.
• Endianess issues with positioning the status bar patch, drawing the bunny scroll screen and fullscreen patches have been fixed.

Unfortunately, some of these changes made it necessary to change the savegame format which is now incompatible to previous releases.

 

https://github.com/fabiangreffrath/woof/releases/download/woof_4.0.0/Woof-4.0.0-win32.zip

Edited March 9, 2021 by fabian

[Eric Claus]

Wonderful, simply wonderful.

[El Juancho]

Wow the mouse feels amazing in this sourceport!

[Eric Claus]

16 hours ago, JuanchoES said:

Wow the mouse feels amazing in this sourceport!

 

Everything just feels snappier or more "performant" in my opinion just like the Chocolate Doom family. Truly I feel we now have a Crispy Boom (well Crispy MBF technically, but Boom rolls off better) and it is glorious. I am already starting to use Woof to record demos for Boom and MBF maps like I use Crispy for Vanilla.  I just use DSDA Doom to test for any desyncs and make sure any potential compat issues are identified as I know Fab is working hard on improving the compat front.

[GoneAway]

52 minutes ago, Eric Claus said:

 

Everything just feels snappier or more "performant" in my opinion just like the Chocolate Doom family. Truly I feel we now have a Crispy Boom (well Crispy MBF technically, but Boom rolls off better) and it is glorious. I am already starting to use Woof to record demos for Boom and MBF maps like I use Crispy for Vanilla.  I just use DSDA Doom to test for any desyncs and make sure any potential compat issues are identified as I know Fab is working hard on improving the compat front.

Could you explain a bit more what you mean by more performant? With uncapped framerate, crispy and woof use the same interpolation strategy as the pr+ ports (which is to say, they introduce a visual lag of 1/35 of a second). At capped framerate, I wouldn't expect there's any noticeable difference. I experimented with mouse code some time ago and Daerik was analyzing dsda-doom graphics based on a camera feed of his hand moving the mouse and the change to his monitor, and there was no visible delay at all. So, if there are some people having problems, I'd like to understand a bit more what causes it. Is it a certain video mode? Uncapped or capped fps?

[Eric Claus]

20 minutes ago, kraflab said:

Could you explain a bit more what you mean by more performant? With uncapped framerate, crispy and woof use the same interpolation strategy as the pr+ ports (which is to say, they introduce a visual lag of 1/35 of a second). At capped framerate, I wouldn't expect there's any noticeable difference. I experimented with mouse code some time ago and Daerik was analyzing dsda-doom graphics based on a camera feed of his hand moving the mouse and the change to his monitor, and there was no visible delay at all. So, if there are some people having problems, I'd like to understand a bit more what causes it. Is it a certain video mode? Uncapped or capped fps?

 

Honestly it is hard for me to explain, and it might just be a personal thing, but I will do my best.

 

First of all I will admit at least for me as I said it could just be in my head, maybe something with how the graphics are perceived in my eye and movement which should be the "same" and yet just feels smoother somehow at times.  Back when I was first comparing at the time though some of that could be attributed to the version of PrBoom+ I was using at the time which I think was 2.5.1.4 which I know was famous for using an older SDL version if I remember right.

 

Just for context I run Crispy a hair weird, I like using uncapped framerate but in widescreen I get tearing and warping toward the edge so I have vsync on to smooth it and it looks great.  In DSDA Doom I run the same kind of setup which looks fine as well with the only difference being the resolution is of course the same as my monitor unlike Crispy or Woof (using fullscreen with aspect ratio correction on the widescreen).

 

So in terms of actual different settings/mechanics the only thing I could think of is the resolution which I know shouldn't cause any issue in and of itself but that perhaps could be the cause, and not so much from the actual mechanics but how my mind tracks things on screen.

 

As an aside I also hope I didn't come across as knocking DSDADoom or any other source port and I appreciate the hard work you and others have poured into PRBoom+ and DSDADoom, and it's a port I often reach for and I feel serves as a great measuring stick for all sorts of things.  It sounds like others have said some similar things, and maybe it's for a similar reason, something just feels right maybe because there is just something they prefer about a port or the presentation seems a hair more to their liking which is also why I said "performant" as I couldn't think of a better word.  Hopefully this helps out some even if it's just a weird piece of anecdata and I wouldn't even say it was a real "problem" for me at all.

 

 

 

[GoneAway]

Thanks for the detailed post!

[Ar_e_en]

On 3/8/2021 at 9:48 AM, fabian said:

Woof! 4.0.0

• Support for the "MUSINFO" lump has been added (@rfomin).

I got version 4.0.0 now, and map 01 of Ancient Aliens still crashes in the middle of the 2nd musical track.

[fabian]

7 minutes ago, Ar_e_en said:

I got version 4.0.0 now, and map 01 of Ancient Aliens still crashes in the middle of the 2nd musical track.

 

Do you have some "special" system that you are running the game on? Which OS is this? Do you have a chance to start the game from a console/terminal window and print the output?

[Dwimepon]

Hey, just wanted to say I've been using this source port for a little bit now, and it's just fantastic! It's great to be able to play old Boom / MBF maps in full screen and in the original low-res without the hassle of setting up DOSBox for it.

Thanks for your hard work!

[Ar_e_en]

3 hours ago, fabian said:

 

Do you have some "special" system that you are running the game on? Which OS is this? Do you have a chance to start the game from a console/terminal window and print the output?

Manjaro Linux and the version of Woof 4.0.0 is downloaded from the AUR. I always start Woof through the terminal.

I can copy the terminals output text and post it here. Should I post the results of my regular program launch or should I launch the program with some specific parameters?

[fabian]

I am interested in the entire output to the terminal until the crash. Please post it here or by PM, thanks!

[Ar_e_en]

I sent the output as a message! I also tested map 30 of Valiant - it also crashes, but in a different way. The music change in Valiant works fine up until the point where I exit the level or restart the level after the music change.

[Ar_e_en]

On a side note: I once beat Valiant on Woof version 2.3.2. There was no music change in map 30 at all, but there were also no crashes.

[fabian]

Found and fixed, thanks!

https://github.com/fabiangreffrath/woof/commit/fbc84217530221a6e3d465876ac1b5b09d12c351

 

[Ar_e_en]

The crashes have stopped! It works now!