fabian Posted May 18, 2020 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. 0 Quote Share this post Link to post
Woolie Wool Posted May 31, 2020 (edited) 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. Edited May 31, 2020 by Woolie Wool 1 Quote Share this post Link to post
wesleyjohnson Posted May 31, 2020 (edited) 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 May 31, 2020 by wesleyjohnson 0 Quote Share this post Link to post
fabian Posted June 1, 2020 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? 0 Quote Share this post Link to post
Woolie Wool Posted June 1, 2020 (edited) 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 Edited June 1, 2020 by Woolie Wool 1 Quote Share this post Link to post
fabian Posted June 2, 2020 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? 0 Quote Share this post Link to post
ironicmoustache Posted June 3, 2020 (edited) 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 June 3, 2020 by ironicmoustache 1 Quote Share this post Link to post
Woolie Wool Posted June 3, 2020 (edited) 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. Woof GZDoom (note the absence of the red pentagram in this screenshot is a bug in GZDoom, the floor should look like the top screenshot) Edited June 3, 2020 by Woolie Wool 0 Quote Share this post Link to post
fabian Posted June 3, 2020 Hm, this could also be an extra tall texture in deepsea format. I'll have to check that. 0 Quote Share this post Link to post
fabian Posted June 3, 2020 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. 2 Quote Share this post Link to post
ironicmoustache Posted June 3, 2020 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! 1 Quote Share this post Link to post
Woolie Wool Posted June 5, 2020 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. 1 Quote Share this post Link to post
fabian Posted June 6, 2020 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! 0 Quote Share this post Link to post
Siggi Posted June 7, 2020 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? 0 Quote Share this post Link to post
fabian Posted June 7, 2020 Not out of scope, but surely pretty low on the priority scale. 0 Quote Share this post Link to post
Woolie Wool Posted June 7, 2020 Why not incorporate UMAPINFO instead since it is used by far more ports and is vastly more powerful? 0 Quote Share this post Link to post
Siggi Posted June 7, 2020 (edited) 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. Edited June 7, 2020 by Siggi 0 Quote Share this post Link to post
fabian Posted June 7, 2020 Because this would be a very invasive change mangling with the innards of nearly every part of the engine. 0 Quote Share this post Link to post
maxmanium Posted June 7, 2020 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. 0 Quote Share this post Link to post
fabian Posted June 7, 2020 (edited) 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 June 7, 2020 by fabian 3 Quote Share this post Link to post
Get Phobo Posted June 7, 2020 On 3/11/2020 at 12:11 AM, Urthar said: Ran a quick test. What mod is that? 0 Quote Share this post Link to post
fabian Posted June 9, 2020 (edited) I have just released Woof! 1.2.2: The code has been prepared to compile with GCC 10.1. Support for tall textures and sprites in DeePsea format has been added. Missing textures are now treated as non-fatal. https://github.com/fabiangreffrath/woof/releases/download/woof_1.2.2/Woof-1.2.2-win32.zip Edited June 9, 2020 by fabian 4 Quote Share this post Link to post
valkiriforce Posted June 9, 2020 Got an error that says libgcc_s_dw2-1.dll was not found when trying to launch it. 0 Quote Share this post Link to post
fabian Posted June 9, 2020 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? 0 Quote Share this post Link to post
ironicmoustache Posted June 9, 2020 (edited) 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! Edited June 9, 2020 by ironicmoustache 0 Quote Share this post Link to post
Baron Pampa Posted June 10, 2020 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. 0 Quote Share this post Link to post
fabian Posted June 10, 2020 @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; 0 Quote Share this post Link to post
Baron Pampa Posted June 11, 2020 @fabian It does:). Will you include it in the main branch? It's great to have a reliable source port with such a wide compatibility. Prboom+ is wonky on this machine, gzdoom doesn't support it, all the other ports I've tried have minor annoyances not present in Woof. 1 Quote Share this post Link to post
Woolie Wool Posted June 12, 2020 (edited) Avactor now runs almost perfectly in Woof, except that it doesn't load IWAD textures that are used for locked door markers, for instance on map01: In addition, there were alignment errors on the chains in the main arena of map05: In addition, tutti-frutti like behavior with certain textures like the sky in Eviternity map26 (the opening lift now looks fine) still exists. Edited June 12, 2020 by Woolie Wool 0 Quote Share this post Link to post
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.