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

7 hours ago, rfomin said:

BetaSkullAttack wasn't exported to BEX in MBF. Thanks for the report, it will be fixed in the next release.

 

So BetaSkullAttack only ever worked with .deh files?

Share this post


Link to post
10 hours ago, Xyzzy01 said:

Thank you for working on this port, I see it still has the compat options menu where I can turn things on or off; I was missing that when trying to play my older WADs that needed it in DSDA-Doom!

If you have a list of wads and the adjustments you needed to make, I would appreciate it. I'd like to make these automatically load with the wads so users don't need to think about it.

Share this post


Link to post

Oh, that'd be really cool! It was only a couple WADs now that I think about it:
 

Spoiler

Confinement.wad 

MAP31: In addition to needing to be run in -cl11 in a -cl9 mapset, it also needs ghost monsters turned on for one encounter... It was my first boom-format map so I'm willing to give my early 2018 self some slack, maybe.

 

conf256b.wad 

MAP07: Needs the lost soul limit turned on.

MAP12: Needs ghost monsters turned on. Both maps have text screens before them mentioning as much.
 

 

Share this post


Link to post

I was testing Woof! 7.0.0 and I noticed that in widescreen mode, on the sides the image is cut by a few pixels. I'm playing in 16:9 FullHD 1080p

 

257847377_DesktopScreenshot2021_10.21-13_27_16_46.png.ebdbc0ddc2439dc98d0a2dd90260977a.png

 

537782924_DesktopScreenshot2021_10.21-13_39_31_14.png.719d1925385d1bc3d60415de54545b6a.png

Share this post


Link to post
58 minutes ago, fabian said:

I am trying to give an explanation to this here (please read to the end): https://github.com/fabiangreffrath/crispy-doom/issues/521

I tried to understand the explanation of the link indicated ... I did not understand why with the 856x480 resolution scaled to 1920x1076, the cut pixels are on the sides and not above and below.

Anyway I thought it was a bug so thanks for the reply.

Share this post


Link to post

I remembered trying Crispy-doom and the cropping wasn't that noticeable, in fact here is a screenshot of Crispy-doom:

904498681_DesktopScreenshot2021_10.21-18_55_58_22.png.2f5103d775aadfb3e08d58c7d194dd5d.png

In fact here it is almost invisible (it will be 2 pixels per side)

Share this post


Link to post
15 minutes ago, fabian said:

Woof! uses the same formula as Crispy in "adjust to screen" mode. 

I don't doubt it, but the result is strangely different (you can see it from the pictures). However I don't want to insist, I just wanted to point this out.

Share this post


Link to post

Might be a silly question, but I seem unable to create different save folders like in Crispy. I tried to launch Woof! with both -savedir foldername and -save foldername but neither seems to actually do anything.

Is it just a case of it not being implemented yet? It's a minor issue, but it's a nice QoL for someone like me that has 10+ .wads in progress at the same time.

P.S: this source port replaced prboom+ for me, it feels really good, it has pretty much everything I could wish for, thank you Fabian, from this to Crispy and prboom+ it feels like your name is attached to everything about "modern" Doom. Here's hoping that you receive an Espi award soon.

Edited by rzh

Share this post


Link to post
12 minutes ago, rzh said:

Might be a silly question, but I seem unable to create different save folders like in Crispy. I tried to launch Woof! with both -savedir foldername and -save foldername but neither seems to actually do anything.

Is it just a case of it not being implemented yet? It's a minor issue, but it's a nice QoL for someone like me that has 10+ .wads in progress at the same time.

No, we don't have a -savedir parameter yet.

Share this post


Link to post
1 minute ago, fabian said:

No, we don't have a -savedir parameter yet.

Got it, thanks for the quick response!

Share this post


Link to post
57 minutes ago, fabian said:

No, we don't have a -savedir parameter yet.

 

What? I just tried and the command "-save" works perfectly to indicate a different directory (like in mbf)

 

  // set save path to -save parm or current dir

  basesavegame = M_StringDuplicate(D_DoomPrefDir());       //jff 3/27/98 default to current dir
  if ((i=M_CheckParm("-save")) && i<myargc-1) //jff 3/24/98 if -save present
    {
      if (!stat(myargv[i+1],&sbuf) && S_ISDIR(sbuf.st_mode)) // and is a dir
      {
        if (basesavegame) (free)(basesavegame);
        basesavegame = M_StringDuplicate(myargv[i+1]);
      }
      else
        puts("Error: -save path does not exist, using current dir");  // killough 8/8/98
    }

 

Edited by fran

Share this post


Link to post
9 minutes ago, fran said:

What? I just tried and the command "-save" works perfectly to indicate a different directory (like in mbf)

 

 Oh my, sorry! I literally just checked for -savedir and didn't even realize we already inherited the -save parameter from MBF. :D

Share this post


Link to post
1 hour ago, fran said:

 

What? I just tried and the command "-save" works perfectly to indicate a different directory (like in mbf)

 


  // set save path to -save parm or current dir

  basesavegame = M_StringDuplicate(D_DoomPrefDir());       //jff 3/27/98 default to current dir
  if ((i=M_CheckParm("-save")) && i<myargc-1) //jff 3/24/98 if -save present
    {
      if (!stat(myargv[i+1],&sbuf) && S_ISDIR(sbuf.st_mode)) // and is a dir
      {
        if (basesavegame) (free)(basesavegame);
        basesavegame = M_StringDuplicate(myargv[i+1]);
      }
      else
        puts("Error: -save path does not exist, using current dir");  // killough 8/8/98
    }

 

So if I'm reading this correctly, in order to work I have to create a folder and put the entire path as a launch parameter?

Share this post


Link to post
22 minutes ago, rzh said:

So if I'm reading this correctly, in order to work I have to create a folder and put the entire path as a launch parameter?

That's right, from my testing it works like this:

woof -file scythe.wad -save .\scythe

 

Share this post


Link to post

Speaking of command-line, Batch files for Woof haven't ever worked for me at all ever since I first got the port. Shortcuts do work though, and all other ports seem to work fine. Any suggestions?

Share this post


Link to post

Let's say, "woof.bat" on the same folder as woof.exe, with the following contents:

woof(.exe) -file Valiant.wad

or

woof(.exe) -iwad doom2.wad -file Valiant.wad

As implied, the parentheses mean that I tried both with and without the ".exe" extension. The command-line shows up for a brief moment, and nothing happens.

Share this post


Link to post

It's weird, it works perfectly fine for me, this is what I wrote for Lunatic

woof.exe -iwad doom2.wad -file Lunatic.wad -complevel 9

 

Share this post


Link to post
10 minutes ago, Lol 6 said:

It's weird, it works perfectly fine for me, this is what I wrote for Lunatic


woof.exe -iwad doom2.wad -file Lunatic.wad -complevel 9

 

'-complevel 9'? Does Woof know how to treat those numbers?

Share this post


Link to post
2 minutes ago, Alaux said:

'-complevel 9'?

Yes, it's a boom format map, so I use complevel 9. For valiant I think it's complevel 11

Share this post


Link to post
2 minutes ago, Lol 6 said:

Yes, it's a boom format map, so I use complevel 9. For valiant I think it's complevel 11

I was asking because as far as I know Woof only has 4 complevels, unlike PrBoom+ which has many more for specific versions and is the one to use said numbers, although now that I check Woof's readme it apparently can also work with numbers instead of names.

Share this post


Link to post
1 minute ago, Alaux said:

I was asking because as far as I know Woof only has 4 complevels, unlike PrBoom+ which has many more for specific versions and is the one to use said numbers, although now that I check Woof's readme it apparently can also work with numbers instead of names.

Here's the doomwiki page

Spoiler

imagen.png.5f1795eab2f2c152ae5cc850e9f167d4.png

 

Share this post


Link to post
4 minutes ago, Alaux said:

I was asking because as far as I know Woof only has 4 complevels, unlike PrBoom+ which has many more for specific versions and is the one to use said numbers, although now that I check Woof's readme it apparently can also work with numbers instead of names.

 

works as an alias for the differents complevels in woof

 

// [FG] support named complevels on the command line, e.g. "-complevel boom",

static int G_GetNamedComplevel (const char *arg)
{
  int i;

  const struct {
    int level;
    const char *const name;
    int exe;
  } named_complevel[] = {
    {109, "vanilla", -1},
    {109, "doom2",   exe_doom_1_9},
    {109, "1.9",     exe_doom_1_9},
    {109, "2",       exe_doom_1_9},
    {109, "ultimate",exe_ultimate},
    {109, "3",       exe_ultimate},
    {109, "final",   exe_final},
    {109, "tnt",     exe_final},
    {109, "plutonia",exe_final},
    {109, "4",       exe_final},
    {202, "boom",    -1},
    {202, "9",       -1},
    {203, "mbf",     -1},
    {203, "11",      -1},
    {221, "mbf21",   -1},
    {221, "21",      -1},
  };

 

Share this post


Link to post

I thought there was another one that was more accurate to classic MBF than complevel 11 was, but it wouldn't surprise me if that was removed after Pooch became an option.

Share this post


Link to post
12 minutes ago, SiFi270 said:

I thought there was another one that was more accurate to classic MBF than complevel 11 was, but it wouldn't surprise me if that was removed after Pooch became an option.

There was no such complevel, we thought that users would not be interested in it. There are not enough demos/WADs to test complevel 11 properly, so perhaps Woof is still a little closer to MBF than PrBoom+. You can build Woof with the MBF_STRICT option.

Share this post


Link to post

Last night I was recording a demo where I actually play a level (not just testing) and I noticed straight away that Woof was not registering slow mouse movements. To be clear I am not talking about reduced turning resolution while recording. I am reporting ignored input while recording. I've checked on my system (Ubuntu MATE) and Chocolate, Crispy and DSDA all work properly while recording. They "snap" to the next view point after the mouse has moved far enough even though the mouse is moving slowly. Woof (and PrBoom+UM) don't update the view until the mouse is moving fast enough; no matter how far I've moved it. This makes small already difficult adjustments impossible while recording.

 

I'm not sure if I should just open a github issue asking for Crispy-Doom mouse code to be ported or I'm simply missing something. See, I had a far more drastic version of this happen in DSDA-Doom running in wine. I was running it in wine for the wad selection launcher. I fixed it in wine by lowering my mouse's onboard sensitivity and upping the sensitivity slider in the OS. But this has not helped Woof or PrBoom+UM.

 

Any ideas?

Share this post


Link to post
23 minutes ago, HackNeyed said:

I'm not sure if I should just open a github issue asking for Crispy-Doom mouse code to be ported or I'm simply missing something.

The Chocolate-Doom (and Crispy) mouse code was ported a long time ago. I cannot reproduce your problem on Windows. Maybe you changed cfg_mouse_acceleration and mouse_threshold in the config?

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
×