Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
fabian

This is Woof! 14.3.0 (Mar 15, 2024)

Recommended Posts

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

 

doom00.png.fe02b1d671083bf0103646543f10caa0.png

Share this post


Link to post
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.

Share this post


Link to post
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)?

Share this post


Link to post

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

Share this post


Link to post
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. ;-)

Share this post


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

From map 27 of Eviternity, played with the last version

 

doom00.png.159fa03adc856f8ae538b3abb0e57232.png

 

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

doom07.png.09f2e41ea71a3b101e96b4ef01d54934.png

 

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.

Share this post


Link to post
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

 

Share this post


Link to post

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.

Share this post


Link to post
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.

Share this post


Link to post
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)?

Share this post


Link to post

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.

Share this post


Link to post

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:

doom01.png.194eb1d1fd56ea995bde061aec942be0.png

 

PRBoom+

screenshot(2020-11-21)_(03-23-12).png.9805579e431b1eda24579782f1557aec.png

 

 

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.

Share this post


Link to post

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

Share this post


Link to post

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

Share this post


Link to post

 

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.

 

qqscreenshot(2020-11-21)_(04-04-13).png.b190a31620d1750e665a8d18eccb7d97.png

 

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.

galleondoom00.png.6759920023670f2be96589af2efea938.png

 

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!).

shipphappensdoom01.png.4fc05acd9b1d1250900dd81d807b3bf0.png

 

Share this post


Link to post
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

Share this post


Link to post

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

doom00.png.64d7cf0cf4a419db650f0ee09ce82a4c.pngdoom01.png.5df054663eab0570bae28e714d2fd5ab.png

 

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

Share this post


Link to post

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.

Share this post


Link to post
7 hours ago, Ar_e_en said:

Woof:

doom01.png.194eb1d1fd56ea995bde061aec942be0.png

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.

Share this post


Link to post

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

 

Share this post


Link to post
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.

Share this post


Link to post

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

 

Untitled.png.d37a04f4d9bc41478181f5d3d2077766.png

Share this post


Link to post
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?

Share this post


Link to post

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

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×