This is Woof! 14.5.0 (Apr 30, 2024)

[Ar_e_en]

It's map 10 of Valiant. It appears all over the map (as well as some of the other maps).

[maxmanium]

Also, I'm getting slimetrails in Eviternity that don't seem present in any other port. Screenshot is the beginning of MAP15.

 

Edited November 10, 2020 by maxmanium

[fabian]

20 hours ago, maxmanium said:

Also, I'm getting slimetrails in Eviternity that don't seem present in any other port. Screenshot is the beginning of MAP15.

 

Even PrBoom+ has this with the software renderer.

[maxmanium]

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

 

Even PrBoom+ has this with the software renderer.

 

My bad, for some reason I didn't catch this.

 

Question: will Woof ever have support for music-changer things (like those used in aaliens\valiant)?

[Altazimuth]

Fixed an old MBF bug in EE today. Woof! appears to have the same thing. The basic issue is when generating a blockmap because the `if/else` for setting min[xy]/max[xy] is an if else (meaning exclusive). maxx and maxy wouldn't be set properly if the 0th vertex had the largest x or y value of all vertices. It's extremely unlikely but can cause buggy blockmap building.

https://github.com/fabiangreffrath/woof/blob/master/Source/p_setup.c

https://github.com/team-eternity/eternity/commit/d89fae15b55e92f3d88c32f401248ecf99624746

Edited November 13, 2020 by Altazimuth

[fabian]

7 hours ago, maxmanium said:

Question: will Woof ever have support for music-changer things (like those used in aaliens\valiant)?

 

In general, there is no reason against it. Though I remember integration of MUSINFO as rather non-trivial from its impementation in Crispy, including extending savegame formats, etc.

 

6 hours ago, Altazimuth said:

Fixed an old MBF bug in EE today. Woof! appears to have the same thing. The basic issue is when generating a blockmap because the `if/else` for setting min[xy]/max[xy] is an if else (meaning exclusive). maxx and maxy wouldn't be set properly if the 0th vertex had the largest x or y value of all vertices. It's extremely unlikely but can cause buggy blockmap building.

 

Thank you for this! Unfortunately, there is no way I can fix this in Woof! without breaking strict MBF compatibility, because the highest "complevel" I have in Woof! happens to be MBF. ;-)

[fabian]

On 10/7/2020 at 10:36 PM, thearcaalex said:

From map 27 of Eviternity, played with the last version

 

 

This is the "texture not power of 2 wide" problem. I think I am on it, at least I found a working solution for Crispy which I will have to port over. What I don't understand, though, are these little slime trails in the top right corner, I don't have them in Crispy, for example.

 

On 10/7/2020 at 10:43 PM, thearcaalex said:

Also this

 

This is all the same spot when walking from the bridge to the grass, right? I guess this is because the floorlevel for the sector at the gap is at -20480, which makes the engine go nuts.

[jeff-d]

21 hours ago, Altazimuth said:

Fixed an old MBF bug in EE today. Woof! appears to have the same thing. The basic issue is when generating a blockmap because the `if/else` for setting min[xy]/max[xy] is an if else (meaning exclusive). maxx and maxy wouldn't be set properly if the 0th vertex had the largest x or y value of all vertices. It's extremely unlikely but can cause buggy blockmap building.

https://github.com/fabiangreffrath/woof/blob/master/Source/p_setup.c

https://github.com/team-eternity/eternity/commit/d89fae15b55e92f3d88c32f401248ecf99624746

 

I'm really sorry.  I fixed this in my port in 2015 and for some reason I failed to publicise this.

 

https://github.com/jeffdoggett/Doom/commit/14546b818077bcd2b51297c8f2ac05a9cadc2b15#diff-7d32a55729cba3784b056944307ec02973678523890c77f51e0ce45b0df65366

 

[valkiriforce]

I noticed recently when playing in Woof that firing your last shot with the super shotgun causes the weapon to be reloaded despite having no ammo left.

 

Also I'm not sure why this is but a custom switch texture isn't working in Woof, but it seems to work fine in other Boom ports. It's a simple texture lump containing the switch textures as SW1GOTH and SW2GOTH.

[maxmanium]

1 minute ago, valkiriforce said:

I noticed recently when playing in Woof that firing your last shot with the super shotgun causes the weapon to be reloaded despite having no ammo left.

 

Also I'm not sure why this is but a custom switch texture isn't working in Woof, but it seems to work fine in other Boom ports. It's a simple texture lump containing the switch textures as SW1GOTH and SW2GOTH.

 

SSG bug was introduced in Boom and has stayed since. It'd be nice to have a fix but I'm not sure if it's feasible for demo-compatibility reasons. I can ditto the issues with switch textures, specifically one in MAP19 of Eviternity.

[fabian]

11 hours ago, valkiriforce said:

Also I'm not sure why this is but a custom switch texture isn't working in Woof, but it seems to work fine in other Boom ports. It's a simple texture lump containing the switch textures as SW1GOTH and SW2GOTH.

 

SO, did you also provide a SWITCHES lump which adds the SW1GOTH and SW2GOTH pair and assigns it to "episode 3" (i.e. Doom 2)?

[valkiriforce]

I'd have to check with the author - it's currently a resource for a WIP wad and it does seem to have the SWITCHES lump so maybe it was a recent texture addition that was an oversight. I just figured I'd bring it up in case it was anything else.

[Ar_e_en]

So, as a curiosity - I decided to test out my own submission to @Scotty 's Boom mapping project that uses OTEX 1.1 textures (made for PRBoom+ complevel 9) in Woof.

 

My map, as well as maps by other people participating in the project can be found here:

Spoiler

 

 

And already an oddity occurred - the sky fucked up:

Spoiler

Woof:

 

PRBoom+

 

 

Now, the map was made for PRBoom+ - so it screwing up in Woof is understandable, but from what I gathered - this technically shouldn't happen on a MBF-type port. The sky texture was implemented with linetype 271 - which (I have been told) is a linetype that was introduced in the original MBF. The only other thing that might be screwing with this is this one other linetype - linetype 337 (used in ZDoom or GZDoom type ports). Those (besides any standard Vanilla or Boom) linetypes are the only "unique" linetypes that I used in the map.

[Ar_e_en]

Slight update: I made a temporary copy of the map without linetype 337 and the sky is still bugged.

[plums]

@Ar_e_en the sky texture is a tall texture, which IIRC still don't work in Woof? Or it might have something to do with how SLADE handles tall graphics. Anyhow nothing to do with the linedef type.

[Ar_e_en]

 

18 minutes ago, plums said:

@Ar_e_en the sky texture is a tall texture, which IIRC still don't work in Woof? Or it might have something to do with how SLADE handles tall graphics. Anyhow nothing to do with the linedef type.

 

Well, it looks more wide than tall. I guess the vertical size of the texture can have an effect on this.

 

 

I guess any map that uses OTEX might experience this from time to time if used with Woof. Weird thing tho - I tested some other maps from other authors on the project and there were different results:

 

Spoiler

Galleon.wad by Scotty didn't have the sky bug, but it did have the standard magenta line bug.

 

ShipHappens.wad by A2Rob does have the sky bug (but the colors are different, also the line is not in the middle of the sky, it's at the very top!).

 

Edited November 21, 2020 by Ar_e_en

[plums]

8 minutes ago, Ar_e_en said:

Well, it looks more wide than tall. I guess the vertical size of the texture can have an effect on this.

It doesn't matter how wide it is (as long as it's a power of two), it's that a texture is higher than 128px. (or maybe just isn't a power of two?)

 

Can you link galleon.wad?

 

Can you also try using OSKY39 in your map? Since it's a 256px tall texture

[Ar_e_en]

I made a little test map with 3 skies - OSKY39, OSKY40 and the first Vanilla sky from DOOM 2.

 

The skies act differently! The two custom skies have the bug, but they are different and the normal sky works just fine! I guess the vertical size really does have an effect on this bug.

 

Also, here is the post where Scotty gives his map (full name - "Gangbang Galleon", file name - "Galleon.wad"): https://www.doomworld.com/forum/post/2218034

Edited November 21, 2020 by Ar_e_en

[Ar_e_en]

One thing I forgot to mention: Galleon.wad and my map don't have OTEX_1.1.WAD implemented into the wads themselves, you have to load the texture pack after the main PWAD in order for the maps to work.

[fabian]

The tall texture bug will be fixed in the next release. 

[Gez]

7 hours ago, Ar_e_en said:

Woof:

It's using a tall patch (1024x200, a patch is tall if it's taller than 128) and the metadata gets interpreted as pixels. That's why you have these two lines of pixels across the sky. If you pay attention to the colors of the lines, you'll notice the light tan one corresponds to palette index 128 and the brown one to palette index 72: each time you see them in a column of sky texture, it means there's the start of a new column span at offset 128 with length 72, but it gets interpreted as pixel data instead of the metadata it actually is.

[fabian]

I have just released Woof! 3.0.0:

• The player coordinates widget on the Automap is now optional.
• Sounds may now be played in their full length. However, this only applies to sounds originating from (removed) map objects, not to those that emerge "in the player's head".
• All textures are now always composed, whether they are multi-patched or not. Furthermore, two separate composites are created, one for opaque and one for translucent mid-textures on 2S walls. Additionally, textures may now be arbitrarily tall.
• A new wrapping column getter function has been introduced to allow for non-power-of-two wide mid-textures on 2S walls.
• Parts of the renderer have been upgraded to use 64-bit integer types.
• Empty DEHACKED lumps are now skipped.

This release should fix all known rendering issues that have been reported so far!

 

https://github.com/fabiangreffrath/woof/releases/download/woof_3.0.0/Woof-3.0.0-win32.zip

 

[fabian]

On 10/14/2020 at 5:12 PM, RonnieColeman said:

weapon-bobbing-while-firing

 

I have added this in GIT, it will be in the next release.

[Smite of Disrespect]

TY. The new update looks phenomenal. I've been using Woof to play Valiant even before the fix, and with the weird purple lines gone, everything looks great. I used Woof to playback some of those very long Valiant single-segment demos and no problems. Doom feels more like Doom when played through Woof instead of PrBoom.

Is there a way to make Woof work with Doom's statistics? Like Crispy Doom and PrBoom keep track of your level stats with Doom Launcher, but not Woof. It's great for both casual playing and for speedrunning

 

Edited December 6, 2020 by RonnieColeman

[fabian]

19 hours ago, RonnieColeman said:

TY. The new update looks phenomenal. I've been using Woof to play Valiant even before the fix, and with the weird purple lines gone, everything looks great. I used Woof to playback some of those very long Valiant single-segment demos and no problems. Doom feels more like Doom when played through Woof instead of PrBoom.

 

Thank you very much for the positive feedback!

 

19 hours ago, RonnieColeman said:

Is there a way to make Woof work with Doom's statistics? Like Crispy Doom and PrBoom keep track of your level stats with Doom Launcher, but not Woof. It's great for both casual playing and for speedrunning

 

Sure I could add support for this! In fact, Woof already supports dumping of map statistics using the same -statdump parameter and file format as Chocolate Doom. So, it's possible that in turn Doom Launcher needs to add support for Woof?

[wrkq]

On 12/7/2020 at 8:58 AM, fabian said:

So, it's possible that in turn Doom Launcher needs to add support for Woof?

It sure did, but someone had to ask the author to do it, so... @RonnieColeman, you're welcome. :)

https://github.com/nstlaurent/DoomLauncher/issues/223

[fabian]

Great, thanks a lot!

[Smite of Disrespect]

Holy crap, ty! This changes things. I've been using DSDA-Doom to finish out my Valiant playthrough simply because I don't play with saves and the stats help me remember where I am in my playthrough. I think I'll await for the official DL update, as I have deleted all my stats before and I don't wanna do that again

[Spie812]

Using 3.0.0, widescreen status bars (at least the one in Rush 2 here) end up looking like this:

 

Edited January 5, 2021 by Spie812

[Smite of Disrespect]

I didn't even know Woof ran in widescreen. How did you do that?

I don't think Woof supports widescreen huds, hence the errors.