This is Woof! 12.0.2 (Dec 13, 2023)

On 3/11/2020 at 11:04 AM, Urthar said:

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

Have the demos been recorded with a Mac build of PrBoom+?

Hey i've tried to run NOVA 3 and it crashes on MAP01, what's going on? The text file says "for any boom compatible sourceport" and "Tested With PrBoom+ 2.5.1.5".

https://www.doomworld.com/idgames/levels/doom2/Ports/megawads/nova3

7 hours ago, drfrag said:

Hey i've tried to run NOVA 3 and it crashes on MAP01, what's going on?

This level is missing a blockmap. By pure incident, I added a check for this just yesterday, so the map now works with a current GIT snapshot.

7 hours ago, drfrag said:

The text file says "for any boom compatible sourceport" and "Tested With PrBoom+ 2.5.1.5".

https://www.doomworld.com/idgames/levels/doom2/Ports/megawads/nova3

Nowadays, "boom compatible" means PrBoom+ with '-complevel 9'. Nobody bothers to check maps with the original ports anymore.

Good, but MAP03 has a missing first sidedef and i guess it will also crash. It crashed on "Chocolate ZDoom" 2.1.8.

19 minutes ago, drfrag said:

Good, but MAP03 has a missing first sidedef and i guess it will also crash. It crashed on "Chocolate ZDoom" 2.1.8.

Nope, MAP03 loads fine. MBF already catches these errors: https://github.com/fabiangreffrath/woof/blob/master/Source/p_setup.c#L459

On 3/21/2020 at 4:56 AM, fabian said:

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".

If you ever considered doing a "Crispy MBF/Woof" sometime after Woof is feature-complete, that's something I know I would like to see.  If such a port existed, it would completely supplant my use of Crispy Doom and cut greatly into my use of GZDoom - no offense to either you or Graf of course. :)

What I might add is interpolated player view. However, I'm still reluctant to adding interpolation for all maps things, moving sectors, scrolling walls, etc. 

8 hours ago, fabian said:

What I might add is interpolated player view. However, I'm still reluctant to adding interpolation for all maps things, moving sectors, scrolling walls, etc. 

You don't have to, I totally respect what this project is trying to be.  I was just suggesting something that could come after, as a different project.

10 hours ago, fabian said:

What I might add is interpolated player view. However, I'm still reluctant to adding interpolation for all maps things, moving sectors, scrolling walls, etc. 

So, what exactly does that mean?

45 minutes ago, maxmanium said:

 

So, what exactly does that mean?

Moving around and turning will be smooth but when you are looking at platforms going up/down they will be at 35fps, same as scrollers etc. Projectiles, too, I guess.

55 minutes ago, Voltcom said:

Forgive my newbishness, I downloaded this source port but.... umm where is the executable that launches it? I didn't see any program.... Please help.

Just look for a dog symbol with a D above his head. This is the Windows 32bit version (on Windows 7 if you can't tell). Hope this picture helps! I tested it last night and it works okay for me (besides the mouse sensitivity being slow). Just up it and it's fine. There is no acceleration so that's why (not that i use it anyways lol).

I have just released Woof! 1.2.0:

• Precaching of all sound effects (with normal pitch) has been added, optional but enabled by default.
• A -nooptions parameter has been added to avoid the loading of OPTIONS lumps embedded into WAD files.
• Blockmaps are now always rebuilt if their lumps are found too short.
• Missing rotations for a sprite frame are now non-fatal.
• Additional states, sprites and mobjtypes have been added for use in Dehacked patches.
• Demo compatibility with Boom 2.02 has been further improved.
• The automap now updates during playing.
• A "demowarp" feature has been added to fast-forward to a desired map in a demo, e.g. -playdemo 30uv666.lmp -warp MAP10.
• Compatibility with the Doom v1.2 IWAD has been further improved.

https://github.com/fabiangreffrath/woof/releases/download/woof_1.2.0/Woof-1.2.0-win32.zip

I like the port so far! A few questions I have though:

How do I enable the secret message? Currently there doesn't seem to be option for enabling them, which makes finding secrets a bit odd for me.

Option for auto running? I couldn't find this either.

Saving the resolution setting? Currently, Woof keeps reverting the resolution back to the same small size. I would like it if there was an option for it to remember going to full screen windowed.

A few other things I've noticed:
The balance of the sliders in some of the menus seems a bit strange. For example: even on the lowest possible setting, the music is still pretty loud. Louder than the sound effects, even when the sound effects slider remains untouched.

Similarly, the mouse sensitivity slider could use more sensitivity IMO. I have it set to max currently and it still doesn't feel quite as smooth as I would like it.

These are just some observations from having played the new version just now. I hope they are of use and I wish you good luck on developing Woof!

Thanks for your feedback!

2 hours ago, Agentbromsnor said:

How do I enable the secret message? Currently there doesn't seem to be option for enabling them, which makes finding secrets a bit odd for me.

This feature has never been in MBF nor in Boom nor Vanilla Doom.

2 hours ago, Agentbromsnor said:

Option for auto running? I couldn't find this either.

You can change the key binding for AUTORUN in the key binding menu.

2 hours ago, Agentbromsnor said:

Saving the resolution setting? Currently, Woof keeps reverting the resolution back to the same small size. I would like it if there was an option for it to remember going to full screen windowed.

Do you mean resolution or window size? Because the former is saved but the latter isn't yet. However, if you choose to go fullscreen this will be saved.

2 hours ago, Agentbromsnor said:

even on the lowest possible setting, the music is still pretty loud. Louder than the sound effects, even when the sound effects slider remains untouched.

Yes, that's the notorious Windows bug that prevents to change music and SFX volume for the same process separately,

2 hours ago, Agentbromsnor said:

Similarly, the mouse sensitivity slider could use more sensitivity IMO. I have it set to max currently and it still doesn't feel quite as smooth as I would like it.

Yes, mouse acceleration has been disabled, so you'll have to push the sensitivity slider a bit more than in other ports.

2 hours ago, Agentbromsnor said:

These are just some observations from having played the new version just now. I hope they are of use and I wish you good luck on developing Woof!

Sure they are, thanks again!

Guys, I had some time to kill and implemented uncapped rendering frame rate with frame interpolation (based on @AlexMax's code from Crispy Doom). Please try this build if you like and tell me about any issues you encounter. I am still not sure if this code will ever make it into the master branch, but it's still nice to have a working solution in a branch somewhere.

Woof-1.2.0+uncapped+gitac7eb1b5-win32.zip

I tried Woof! yesterday (the second source port ever ever run by me) and it is a nice platform to play with a vanilla feeling (I bought vanilla classic doom on GOG mid-march and completed this version of D1 and D2 first, then I tried GZDoom for Sigil and NRFTL).

Nevertheless, I have to report a problem: yesterday, doom.wad worked with Woof! but today I get this error message:

Quote

R_TextureNumForName: SW1PANEL not found

All other IWADs still work.

Thanks for trying Woof! It is very unlikely that IWADs stop working overnight. Could you please test with any other source port, e.g. Chocolate Doom orPrBoom+, that the wad file in question is still intact?

I have an IWAD folder for source ports which is seperate from the vanilla Doom GOG folders. So the latter should be not compromised.

I deleted the doom.wad and replaced it with the copy from the vanilla folder. Vanilla and GZDoom work fine. However, the error message on Woof! remains. When I run doom.wad on PrBoom+, the episode selection is missing and the first D2 map is run instead. With many textures missing, causing the well known optic mess.

I remember trying to load a game either with Woof! or PrBoom+ while running another game based on another IWAD (I think it was loading D1 while testing the source ports witn TNT). Therefore it seemed a legit assumption that IWADs may be compromised.

EDIT:It is very weird now: I pulled the wad from the vanilla folder on Woof! and it worked. Same with PrBoom+. If I copy the wad to the desktop it works. But if I pull it from my iwad folder it fails....

SW1PANEL belongs to the first pair of switch textures that is exclusive to Doom 2. So, the engine somehow believes that it is loading a Doom 2 compatible IWAD, but it doesn't. Did you happen to rename the IWAD files? 

1 hour ago, fabian said:

Did you happen to rename the IWAD files?

Filename won't matter, CheckIWAD looks at which lumps are present, right?

34 minutes ago, andrewj said:

Filename won't matter, CheckIWAD looks at which lumps are present, right?

Yes, but if you use drag-and-drop the files are arranged into a proper command line before they could get opened. This is solely based on filenames. So, if you renamed the IWADs, the engine will be unable to detect which file it needs to pass to the "-iwad" parameter. 

For example, you rename doom.wad to whatever.wad and drag it onto the engine's icon. Then the engine will fail to detect it as an IWAD and will pass it to the "-file" parameter instead. The engine will thus load the default IWAD which is doom2.wad. This IWAD will contain all the necessary lumps to identify the game as Doom 2. However, at this point its texture directory will get overridden by the one from doom.wad, which was loaded as a PWAD with a different name. Thus, the engine will fail to detect the first Doom 2 exclusive textures. 

Seems a bit bizarre that there's all that code for checking the contents of an IWAD to determine which one it is, but some parts also need to check the name too.

Reminds me of a plane which had two sensors for determining altitude, and when one failed the computer didn't know which one was right and which one was wrong, so it showed the pilot one of them (the wrong one) and it ultimately lead to the plane crashing.

9 hours ago, fabian said:

SW1PANEL belongs to the first pair of switch textures that is exclusive to Doom 2. So, the engine somehow believes that it is loading a Doom 2 compatible IWAD, but it doesn't. Did you happen to rename the IWAD files? 

No, I see no reason to do that.

Loading doom.wad with Woof! works if the wad is dumped anywhere but not in the path where the error occurs. Oddly, that path is "nothing special".

Different question: why is the number of saves limited?

2 hours ago, GenColossus said:

No, I see no reason to do that.

Loading doom.wad with Woof! works if the wad is dumped anywhere but not in the path where the error occurs. Oddly, that path is "nothing special".

Does it contain any spaces? 

2 hours ago, GenColossus said:

Different question: why is the number of saves limited?

It has always been like this in Doom. 

On 5/2/2020 at 9:13 PM, fabian said:

 

Does it contain any spaces? 

 

 

It has always been like this in Doom. 

I detected the issue: the problem always occurs if all IWADs (D1, D2, TNT, Plutonia) are together within a single folder, the particular path (which may have spaces) does not matter.

Regarding save slots. OK, the aim is to be close to vanilla. But this ist the most annying feature of many old games.

On 5/3/2020 at 11:01 PM, GenColossus said:

I detected the issue: the problem always occurs if all IWADs (D1, D2, TNT, Plutonia) are together within a single folder, the particular path (which may have spaces) does not matter.

Found and fixed, thanks!

https://github.com/fabiangreffrath/woof/commit/14461435264ccb1887a485b7adba28678e68ca96

I have just released Woof! 1.2.1:

• An FPS counter widget has been added and can be enabled by the SHOWFPS cheat (only if not in automap).
• The default horizontal mouse sensitivity has been increased.
• The code for loading maps with extended nodes has been made endianess-clean (Michael Bäuerle).
• Drag-and-drop for IWAD files has been fixed.

https://github.com/fabiangreffrath/woof/releases/download/woof_1.2.1/Woof-1.2.1-win32.zip

On 5/5/2020 at 11:06 AM, fabian said:

 

Found and fixed, thanks!

 

https://github.com/fabiangreffrath/woof/commit/14461435264ccb1887a485b7adba28678e68ca96

 

I am pleased to help!

I downloaded Woof, but will have to wait until I can get it on a WIndows Machine (I run Linux).

I have experienced moon-walking monsters in my MBF implementation in DoomLegacy.  This persists until I turn off the MBF monster-avoid-hazard option.

An example of the moon-walking is seen in TNT wad, Map01, the group of three imps crowed together with a shotgun.

When they see you, the first two will walk backwards out of the group before they turn.

Has anyone noticed this in MBF before ?
I am trying to find out if this is how MBF behaves, or do I still have an MBF implementation bug.  I have looked for differences between my implementation and the MBF source and cannot find anything to fix.

Now, I expect many people have not noticed this, but once you notice it you cannot stop seeing it.  It has gotten to be annoying.