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

This is Woof! 8.1.0 (Nov 26, 2021) [Updated WinMBF]

Recommended Posts

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.

Share this post


Link to post
1 hour ago, wesleyjohnson said:

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

 

The sources compile cleanly on Linux. In fact, I use it as main development platform. 

Share this post


Link to post

IupbBI4.png

This port is awesome! I wanted a Chocolate Boom for years and what I get instead is...Chocolate MBF?! Fuck yeah!

 

That said, I have noticed some problems when playing modern "MBF compatible" wads in Woof, not nearly as many as MBF itself and none that have crashed the game so far, especially the tutti frutti effect. I also couldn't get the exit stairs to raise in Eviternity map06. Will tutti-frutti be removed (since modern wads seem to assume its absence) in future builds?

 

On 5/18/2020 at 2:04 AM, wesleyjohnson said:

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.

Sounds like the "monsters back out" feature, which is a compatibility flag in MBF under the Enemies menu.

Share this post


Link to post

I tried Woof on my Windows Machine, as I already had the Windows binary downloaded.

There was a bit of difficulty in figuring out the command line switches for selecting a decent screen size.

My first efforts gave me a window about the size of a post-it note.

I am not sure if I read the correct docs for starting it from the command line, so I tried reading some more of the docs.  That did not clarify at all how to select screen size from the command line.

It sure was not going to get selected from reading menus in the post-it note sized version.

Somehow, I finally got it to go fullscreen, which at least gave me menus that I could read.

From the menus, there seems to only be two resolutions, 200 and hi-res (which may be 600 or 720).

So, I am going to suggest an easy to find file in those docs that has some command line examples, like for starting it in hi-res fullscreen from the command line.

 

About the moon-walking.

First thing with Woof, I check with TNT Map01 to see if the 3 imps moon-walk (walk backwards) out from that corner, and no they turned first.

... skip some stuff that nobody cares about ...

So, So, I double check that my method of testing it (from a save game) works in provoking the behavior.  No, now I cannot provoke the moon-walking.

Now, I cannot get it to happen, even with older versions.

The POM must have changed.

 

It would help so much if anyone has seen this in another MBF port (like Woof), and is willing to say so.

 

I got multiple requests from users that they don't like it, and would like for the moon-walking to be fixed.

 

 

Edited by wesleyjohnson

Share this post


Link to post
15 hours ago, Woolie Wool said:

This port is awesome! I wanted a Chocolate Boom for years and what I get instead is...Chocolate MBF?! Fuck yeah!

 

Thank you for the positive feedback! 

 

15 hours ago, Woolie Wool said:

I also couldn't get the exit stairs to raise in Eviternity map06.

 

Oh, I had to modify the stair building function quite a bit to make it demo compatible with both Boom and Vanilla. I hope I didn't break it for MBF in the course. Could you probably send me a savegame of the point right before you hit the switch that should start the stair building? 

 

15 hours ago, Woolie Wool said:

Will tutti-frutti be removed (since modern wads seem to assume its absence) in future builds?

 

The classic Tutti Frutti caused by non-powers-of-2-px high textures is fixed since Boom. What you see is probably caused by single patch translucent textures on 1s walls. Could you send a screenshot of this or also a savegame? 

Share this post


Link to post

The map06 issue with the switches turned out to be my problem (missed a switch) but I have a save of the tutti-frutti-like effect at the start of map26, and just before one of the episode death exits, which are broken in Woof. If you restart map26, you can also see that the fade around you from black to white as the start elevator rises is also broken as it starts already white.

 

 

saves.zip

Share this post


Link to post
On 6/1/2020 at 3:36 PM, Woolie Wool said:

The map06 issue with the switches turned out to be my problem (missed a switch)

 

Phew, good to know!

 

On 6/1/2020 at 3:36 PM, Woolie Wool said:

but I have a save of the tutti-frutti-like effect at the start of map26, and just before one of the episode death exits, which are broken in Woof.

 

Dead players cannot exit levels in MBF unless you enable the "Zombie players can exit levels" compatibility flag.

 

On 6/1/2020 at 3:36 PM, Woolie Wool said:

If you restart map26, you can also see that the fade around you from black to white as the start elevator rises is also broken as it starts already white.

 

This sounds like a gradual lighting effect. Have you checked the "Tagged doors don't trigger special lighting" compatibility flag?

Share this post


Link to post

As someone who almost exclusively plays vanilla/limit-removing WADs so that I can play with Crispy, this is something of a godsend for my chunky/slightly-less-chunky graphics-loving self. Gave it a whirl recently and it might become my port of choice for Boom-compatible stuff purely for aesthetic reasons. Any plans to implement an uncapped/interpolated framerate? Understandable if it's not within the scope of the port, though.

Edited by ironicmoustache

Share this post


Link to post
7 hours ago, fabian said:

 

Phew, good to know!

 

 

Dead players cannot exit levels in MBF unless you enable the "Zombie players can exit levels" compatibility flag.

 

 

This sounds like a gradual lighting effect. Have you checked the "Tagged doors don't trigger special lighting" compatibility flag?

"Zombie players can exit levels" fixed the death exits, but the beginning of map26 is a texture effect--you can see the banding going up in GZDoom.

doom32.png.104138ab93347f7ad97799d1478bedff.pngWoof

Screenshot_Doom_20200602_223106.png.6e0d345ce94e1c2060603d0acc3e6c6c.pngGZDoom (note the absence of the red pentagram in this screenshot is a bug in GZDoom, the floor should look like the top screenshot)

Edited by Woolie Wool

Share this post


Link to post

Hm, this could also be an extra tall texture in deepsea format. I'll have to check that. 

Share this post


Link to post
6 hours ago, ironicmoustache said:

Any plans to implement an uncapped/interpolated framerate? Understandable if it's not within the scope of the port, though.

 

It is already prepared in a branch that I haven't merged yet. I hope you understand that this is quite a borderline feature for a port which is focused on being faithful to MBF.exe. 

Share this post


Link to post
1 minute ago, fabian said:

 

It is already prepared in a branch that I haven't merged yet. I hope you understand that this is quite a borderline feature for a port which is focused on being faithful to MBF.exe. 

 

Of course. That's completely understandable and honestly it wouldn't be a deal-breaker if not present, given the focus of the project. That said, good to know that it's on the cards. Thanks for the great work!

Share this post


Link to post

doom45.png.bf8ae3cdbe19b16c31391e24b5026abf.png

I've started playing Mutiny (40oz's megawad, not my old gameplay mod) with it and while the first several levels work fine, map09 brings up a problem that I've seen with several other "Boom-compatible" or "MBF-compatible" wads: they have all been tested on ports that can handle invalid texture names. On PrBoom+ this will lead to an HOM at most, but with Woof this is causes the game to crash while loading the level. I think there should at least be the option to ignore invalid texture names for the sake of compatibility.

Share this post


Link to post
On 6/3/2020 at 5:26 AM, Woolie Wool said:

but the beginning of map26 is a texture effect--you can see the banding going up in GZDoom.

 

This was indeed a tall texture in DeePsea format, for which I just added support to Woof!

 

20 hours ago, Woolie Wool said:

but with Woof this is causes the game to crash while loading the level.

 

Now it doesn't anymore and renders a HOM instead where the textures cannot be found by name.

 

@Woolie Wool Thank you very much for your suggestions and feedback, it is highly appreciated!

Share this post


Link to post

I tried this with wads generated with Oblige and noticed the shuffle music options does not work. Turns out Oblige does this by using the Music Block which is an Eternity Extension to DeHackEd/BEX.

 

Would adding these extensions be within scope for this project?

Share this post


Link to post

As far as DEH/BEX goes I meant all the extensions EE added, not specifically music. The motivation is that apparently those extensions are used and it's not obvious Woof/MBF doesn't support them. I didn't even know they existed until I tried Oblige wads with Woof.

 

I'm not opposed to UMAPINFO though.

Share this post


Link to post

Because this would be a very invasive change mangling with the innards of nearly every part of the engine. 

Share this post


Link to post
6 minutes ago, Woolie Wool said:

Why not incorporate UMAPINFO instead since it is used by far more ports and is vastly more powerful?

 

Has a proper UMAPINFO standard been created yet? Couldn't seem to find it anywhere.

Share this post


Link to post
23 minutes ago, Siggi said:

it's not obvious Woof doesn't support them.

 

Woof is pretty much supposed to be MBF.exe brought to 2020, so I don't know what you guys expect sometimes. 

Edited by fabian

Share this post


Link to post

Oh, I suspect this is due to the self-built zlib with the new GCC version. What if you replace that lib with the one from Crispy? 

Share this post


Link to post

Had to copy both the libgcc_s_dw2-1 and libwinpthread-1 dlls from Crispy into the Woof! folder before it would run. Not really a question of "replacing" as the zipfile linked doesn't include either dll? Works fine after copying both though. Thanks again for the work you're putting into this!

Share this post


Link to post

Hi!

Some good news: this port compiles without issues on PinebookPro with ARM CPU
Bad news: Movement key to the left or backward makes the player run in other direction with extreme speed. Very weird.

Share this post


Link to post

@Baron Pampa Does this patch help?
 

--- a/Source/d_ticcmd.h
+++ b/Source/d_ticcmd.h
@@ -37,8 +37,8 @@
 // plus a checksum for internal state consistency.
 typedef struct
 {
-    char       forwardmove;    // *2048 for move
-    char       sidemove;       // *2048 for move
+    signed char        forwardmove;    // *2048 for move
+    signed char        sidemove;       // *2048 for move
     short      angleturn;      // <<16 for angle delta
     short      consistancy;    // checks for net game
     byte       chatchar;

 

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
×