This is Woof! 14.3.0 (Mar 15, 2024)

[liPillON]

@game you might consider using this

 

 

[Pixel Fiend]

46 minutes ago, Delfino Furioso said:

@game you might consider using this

 

 

 

Ah, tried that. Nice effort but completely different and I never use it. I think mainly because there was something off about some of the brightmaps. There's also brightmaps packs for gzdoom and those are worth using but are hit and miss too. Crispy has consistent natural looking stuff that feels like it should have always been in Doom.

[BigBoy91]

Recorded a Scythe 2 map 08 run and it desyncs when I use the BFG. Recorded with cl2. The BFG uses its vanilla behavior during demo playback. Not sure why that is.

Edited January 8, 2022 by CleaverHeaver

[rfomin]

4 hours ago, CleaverHeaver said:

Recorded a Scythe 2 map 08 run and it desyncs when I use the BFG. Recorded with cl2. The BFG uses its vanilla behavior during demo playback. Not sure why that is.

Do you mean "classic BFG" behavior? We left the option to enable the beta version of BFG as a joke, it will desync with any demo.

[fabian]

Just sayin'...

[Alaux]

I noticed two more oddities:

 

By using any mouse commands (Left/right/middle click or wheel up/down) on the Options menus, the next available thermometer (not the text above it as usual) will be selected, but it can't be interacted with, be it through mouse or keyboard commands (occurs on the Options menu itself, Mouse Sensitivity and Sound Volume menus). Otherwise, if there are no thermometers, a sound will play but nothing will happen (occurs on the General and Setup screens).

 

Also, on the intermission screen, the Total time count doesn't work "properly" like Time and Par do; if Total is greater than both, it will play the Pistol sound as usual but won't be displayed (neither the graphic nor the number) until it is done counting.

[rfomin]

3 hours ago, Alaux said:

By using any mouse commands (Left/right/middle click or wheel up/down) on the Options menus, the next available thermometer (not the text above it as usual) will be selected, but it can't be interacted with, be it through mouse or keyboard commands (occurs on the Options menu itself, Mouse Sensitivity and Sound Volume menus). Otherwise, if there are no thermometers, a sound will play but nothing will happen (occurs on the General and Setup screens).

Thanks, this is fixed in git

 

3 hours ago, Alaux said:

 

Also, on the intermission screen, the Total time count doesn't work "properly" like Time and Par do; if Total is greater than both, it will play the Pistol sound as usual but won't be displayed (neither the graphic nor the number) until it is done counting.

I'm not sure about this, how is this supposed to work? Also, which -complevel are you using? The current behavior should be demo compatible with PrBoom+.

[Alaux]

13 hours ago, rfomin said:

I'm not sure about this, how is this supposed to work? Also, which -complevel are you using? The current behavior should be demo compatible with PrBoom+.

Well, I certainly didn't expect the intermission screen to be affected by complevels, but it might be; the problem is that it seems like I can't properly test it since the results are varying within the same complevel. I did change complevels and start a new game to try to avoid the quirk with saves keeping their complevel.

 

I'll try to explain it with words:

Spoiler

Let's put up a hypothetical scenario: you've just beaten a Map02 which has a Par time of 1:30. It took you a Time of 3:00 to beat the map, and your Total time up until that point is 5:00.

 

Based on this scenario, if you don't skip the intermission screen's counting phase, it seems that no matter the complevel, all of the time counters (Time, Par and Total) will start counting simultaneously. The Time and Par graphics are displayed, but the Total graphic is not.

 

The varying results are that on some occasions, the Total count (both graphic and time number) would show up as soon as Time were done counting. This is what initially only happened with Boom and MBF as the default complevels.

 

On other cases, Total would keep on counting by itself, remaining invisible but still playing the Pistol sound until it was done counting. This was the result that I got on Vanilla and MBF21 at first, but afterwards they behaved the same as Boom and MBF in previous tests.

 

[fabian]

Fixed, thanks for the report. 

[Bytefyre]

Hello!  I noticed something a bit off with the alignment of the extended HUD with certain WADs; there seems to be a wider vertical gap between the status bar and the kills/items/secrets line.  I have a couple of screen caps to share for Ancient Aliens:

 

Woof

 

DSDA-Doom

 

I compared the size of the Ancient Aliens status bar to others where I didn't see this issue and it's identical, and I didn't see any such difference in vertical positioning with Back to Saturn X or Eviternity.  Is this a known issue, and if not, is it something that can be investigated?  Thanks!

[fabian]

The vertical position of the Time/STS widgets depends on the height of the characters of the HUD font - although the widgets are rendered in a different font. I have fixed this in GIT, thanks for the report!

[Bytefyre]

I'm now encountering something else strange, and I'm not sure why.  Ever since I did my own dev build using the latest code from GitHub (in Visual Studio, using x64-Release configuration), the map names won't show up on the automap at all.  Can anyone else confirm this behavior and why it might be occurring?

 

EDIT:  Looks like something with the update for the Time/STS widgets is affecting the automap.  As soon as I set the option to display that to No, the automap showed the map title again.

Edited January 13, 2022 by Bytefyre : Further investigation

[Alaux]

6 minutes ago, Bytefyre said:

Ever since I did my own dev build using the latest code from GitHub (in Visual Studio, using x64-Release configuration), the map names won't show up on the automap at all.

This commit could be related; the logic seems to be fine at first glance, but then again, the previous code also looked good yet did have one small bug.

[fabian]

Could you post one screenshot with the automap enabled and one with it disabled? 

[Bytefyre]

37 minutes ago, fabian said:

Could you post one screenshot with the automap enabled and one with it disabled? 

Sure thing:

 

Time/STS Enabled

 

Time/STS Disabled

[rfomin]

I fixed it in master.

[Bytefyre]

28 minutes ago, rfomin said:

I fixed it in master.

Great!  Thanks so much!

[Lila Feuer]

MAP12: Black Rain in Community Chest 3 has a BFG9000 pickup near the end of the level that according to Doomwiki is suppose to trigger a slow moving crusher when attempting to get it but this never happened to me on Woof! so I'm not sure if I just tripped the linedef weird or what. Thought I'd mention it anyway.

[rfomin]

7 hours ago, Lila Feuer said:

MAP12: Black Rain in Community Chest 3 has a BFG9000 pickup near the end of the level that according to Doomwiki is suppose to trigger a slow moving crusher when attempting to get it but this never happened to me on Woof! so I'm not sure if I just tripped the linedef weird or what. Thought I'd mention it anyway.

I tried to reproduce it but it seems to work. Not sure if I'm doing it right. I also tested all demos from DSDA of this map without desync. Do you have saves or demos of this level?

[fabian]

Probably depends on complevel. 

[Lila Feuer]

@rfomin Sorry I've since moved on and my save is replaced. @fabian I've been on Boom compatibility.

[liPillON]

browsing the commit history over at github I've noticed some pretty major features (fluidsynth, crosshair, etc) are coming.. sweet!

 

release 9.0 incoming?

 

 

[fabian]

3 hours ago, Lila Feuer said:

@fabian I've been on Boom compatibility.

 

Just checked with `-complevel boom` and the crusher indeed crushed me.

 

2 hours ago, Delfino Furioso said:

release 9.0 incoming?

 

We are still in a fast moving state, so no release in the short term. But once it's ready, it will rather be 10 than 9. ;)

[liPillON]

are you really planning to "go microsoft" with the versioning? XD

[fabian]

17 hours ago, Delfino Furioso said:

are you really planning to "go microsoft" with the versioning? XD

 

Yes. Actually, the next version is going to be "Woof! for Workgroups" - and this isn't even a joke. ;)

[LuciferSam86]

Just stumble upon (I've been using it for a week) this source port and I really like it.

It became my main source port when I don't want to use all the bells and whistles of GZDoom.

Thank you for the passion you put in this awesome project :)

[Pixel Fiend]

I wanted to test replacing messages in dehacked, and this worked in prboom+ and crispy, but not in woof:

 

[STRINGS]

GOTREDCARD = Picked up a zoo key

PD_REDK = You need a zoo key to enter

 

I don't have experience with such editing but I'm interested to learn if it's because of some issue?

[rfomin]

5 hours ago, game said:

[STRINGS]

GOTREDCARD = Picked up a zoo key

PD_REDK = You need a zoo key to enter

This works fine for me in Woof:

[Alaux]

I'm not sure if this is intentional or not since the original code does the same thing in some occassions, but I'll mention it anyways:

 

Basically, the following is not totally true (snippet from P_MovePsprites)

// [FG] center the weapon sprite horizontally and push up vertically
else if (center_weapon == 1)
{
  psp->sx2 = FRACUNIT;
  psp->sy2 = WEAPONTOP;
}

By making sx2 equal to FRACUNIT, a one-pixel offset is applied to the sprite, so it is not truly centered. This is not the only instance of such slight offset in the Psprites code (as I said, it happens on some of the original Doom code too), and based on some testing and discussion on the subject, it's present across most if not all non-ZDoom-based ports. However, since this is a setting that deviates from vanilla behavior, it might be a special case. I can't tell if it was kept for compatibility regardless or if it did go unnoticed, I hope I can get some light from people who know.

Edited January 21, 2022 by Alaux

[fabian]

Well, this is the calculation of the weapon sprite bob from p_pspr.c:A_WeaponReady(). It is identical in both Vanilla and MBF:

// bob the weapon based on movement speed
  {
    int angle = (128*leveltime) & FINEMASK;
    psp->sx = FRACUNIT + FixedMul(player->bob, finecosine[angle]);
    angle &= FINEANGLES/2-1;
    psp->sy = WEAPONTOP + FixedMul(player->bob, finesine[angle]);
  }

As you can see, the sx value is based around FRACUNIT. If you disable bobbing by setting player->bob to zero, what remains is FRACUNIT and not zero.