This is Woof! 14.5.0 (Apr 30, 2024)

[Trov]

Honestly I think that's something the WAD needs to fix.

[elborbahquarama]

it's probably just me because i haven't seen anyone mention it but i'm still using an older version of woof (12.0.0) because the latest versions (i don't know with which one it started but i think i tried the last 3 or 4 ones) don't have such a good framerate for me, i use the opening view of the town in comatose as a test, i play with the capped 35 fps option, original image ratio and doubled resolution and in 12.0.0 that opening view runs perfectly for me while in the last 3 or 4 version it's a pretty big drop in framerate (i don't know for the versions between the one that i use and those), but i also tried on dsda (which i pretty much never used) and i have the same drop of framerate here, so i think it's probably just me because everybody uses dsda and nobody had this kind of complaints as far as i know, and i haven't been playing doom a lot lately so i'm perfectly fine using my good old outdated sourceport (i haven't played any very recent wad as far as i can remember, never even tried an mbf21 one yet lol) but i'm just curious as to why those older woof versions run so smoothly for me

[Danfun64]

Could post your system specs? I do realize that Doom is a low end game and Woof isn't the most system intensive of source ports, but knowing what OS you are running and what your hardware is might shed a light on things.

Edited May 5, 2024 by Danfun64

[fabian]

This comparison can only be fair if you run both versions with the exact same resolution, i.e. 400p (200% in 14.x without dynamic resolution).

[elborbahquarama]

yup i ran both with the same resolution, and i have an old computer (it's about 10 years old) and it still works really well but it's on windows 7 so that might just be what causes it!! (i'd have to look up how to know exactly what it's made of as i don't know much about that stuff, it was really good at the time but it was put together a long time ago after all)

[Alaux]

37 minutes ago, elborbahquarama said:

yup i ran both with the same resolution, and i have an old computer (it's about 10 years old) and it still works really well but it's on windows 7 so that might just be what causes it!! (i'd have to look up how to know exactly what it's made of as i don't know much about that stuff, it was really good at the time but it was put together a long time ago after all)

FWIW, my own laptop is also running Win7 and definitely over 10 years old, and yet all versions of Woof I used (around 6.3.1 onward) ran fine.

[Shepardus]

Worth noting that @elborbahquarama is using the opening of Comatose as a benchmark, which is notoriously hard on software renderers. I actually get similar results, much to my surprise (never tried until now, I usually use dsda-doom's OpenGL renderer for this map). Most other software renderers, including dsda-doom, Woof 14.5.0, Crispy Doom, and Eternity Engine (without using the multithreaded renderer), give me about 10 fps after rounding the first bend, but Woof 12.0.2 gives me 20-30 fps. Interestingly, GZDoom's software renderer ends up somewhere in between, around 15-20 fps. I have a pretty old CPU in this computer (Core i7-920, not overclocked) and I'm running Linux (Fedora 39).

[elborbahquarama]

yes, i'm sorry i forgot to say that i don't have any framerate problem with the latest versions of woof at all outside of extreme examples like comatose or the given (which are some of my favorite levels that are notorious for creating framerate problems for a lot of people) and i'm sure i can play almost any of the other 600 or so wads i have in my files without any drop, as shepardus said i use it as a benchmark because if this runs smoothly that means i can be sure that i will never have any problem with anything else, and of course i would never put the performance capabilities of woof in doubt, as it is my favorite program to play one of my favorite games ever, i realise that my message could have been seen as criticising the latest versions of woof but of course this is just me being picky for no reasons at all and just being curious why it happens!! :o

 

edit: also thank you shepardus for giving more info, you were much more thorough than i was haha, interesting to know that it's not just me (though that would have been a more happy news ;_;)!! i wonder what could have caused this subtle change

Edited May 5, 2024 by elborbahquarama

[rfomin]

The performance regression on the Comatose map is due to this change git commit Older versions of Woof do not render distant sprites due to integer overflow.

[fabian]

4 hours ago, rfomin said:

The performance regression on the Comatose map is due to this change git commit Older versions of Woof do not render distant sprites due to integer overflow.

 

Oh, maybe I should better revert that commit and explicitly check for sprite distance instead. 

[fabian]

@rfomin we could make the max vis sprite distance dynamic just as we do for voxels, what do you think?

[rfomin]

59 minutes ago, fabian said:

@rfomin we could make the max vis sprite distance dynamic just as we do for voxels, what do you think?

 

I like the idea. The lack of very distant sprites won't be noticeable at low resolutions anyway - perhaps that's why this overflow was only recently fixed.

[fabian]

This change alone increases my FPS from 9 to 28 in the opening scene of comatose, and I can't even spot any difference.

--- a/src/r_things.c
+++ b/src/r_things.c
@@ -47,6 +47,7 @@
 #include "z_zone.h"
 
 #define MINZ        (FRACUNIT*4)
+#define MAXZ        (FRACUNIT*8192)
 #define BASEYCENTER 100
 
 typedef struct {
@@ -539,7 +540,7 @@ void R_ProjectSprite (mobj_t* thing)
   tz = gxt-gyt;
 
   // thing is behind view plane?
-  if (tz < MINZ)
+  if (tz < MINZ || tz > MAXZ)
     return;
 
   xscale = FixedDiv(projection, tz);

 

[fabian]

On 5/2/2024 at 8:23 AM, Shepardus said:

Is there any way to adjust the word wrapping Woof does with the text on the story screens? Sometimes the split lines take up too much vertical space and they drop off the bottom of the screen. Example from Die Rowdy:

 

Woof:

[...]

 

dsda-doom:

[...]

 

Also dsda-doom:

 

 

Quote

In this case the text has been formatted for widescreen

 

Sorry, but I don't think there is anything like this in Doom. How is a port supposed to know if a text replacement has been created with the expectation that it is drawn to screen with widescreen rendering enabled?

 

 

Edited May 7, 2024 by fabian

[Shepardus]

1 hour ago, fabian said:

Sorry, but I don't think there is anything like this in Doom. How is a port supposed to know if a text replacement has been created with the expectation that it is drawn to screen with widescreen rendering enabled?

What I mean is that in widescreen, Woof leaves a wide margin when it wraps the text; it doesn't use the widescreen area to render text even if the text would fit there. I would suggest wrapping the line when the text reaches the edge of the screen rather than the edge of the 4:3 area. I think that would just be changing F_TextWrite so that instead of calling F_AddLineBreak if (cx+w > SCREENWIDTH), to do so if (cx+w > SCREENWIDTH+video.deltaw).

[fabian]

1 hour ago, Shepardus said:

I think that would just be changing F_TextWrite so that instead of calling F_AddLineBreak if (cx+w > SCREENWIDTH), to do so if (cx+w > SCREENWIDTH+video.deltaw).

 

That's a fair suggestion! I tend to think too complicated sometimes. 

[Devalaous]

On 4/30/2024 at 5:49 PM, fabian said:

Woof! 14.5.0 is released on Apr 30, 2024.

 

A complete list of new features, improvements and bug fixes can be found on the release page:

 

https://github.com/fabiangreffrath/woof/releases/latest

 

Binaries for Windows are available here:

 

https://github.com/fabiangreffrath/woof/releases/download/woof_14.5.0/Woof-14.5.0-win32.zip

https://github.com/fabiangreffrath/woof/releases/download/woof_14.5.0/Woof-14.5.0-win64.zip

 

An AppImage for Linux is available here:

 

https://github.com/fabiangreffrath/woof/releases/download/woof_14.5.0/Woof-14.5.0-Linux.appimage

 

Have a lot of fun!

- Fabian

 

I'm guessing that the dehacked obituary thing will mean my QoL patches with obituaries for ZDoom family ports, will now also work in Woof? Neat!

 

EDIT: Confirmed! My Cleimos 2 patch has a bit at the bottom of its Dehacked that replaces the 'met a Nazi' obituary with 'terminated by a robot', and this popped up when I was killed by the Nazi replacement

Edited May 7, 2024 by Devalaous

[maxmanium]

Is there any reasonable way to fix this without having to do some crazy overhaul of the renderer? I'm guessing not but figured I'd ask anyway.

[s4f3s3x]

I believe reading somewhere it was already fixed in Crispy Doom so I'd assume it is in Woof as well

[maxmanium]

1 minute ago, s4f3s3x said:

I believe reading somewhere it was already fixed in Crispy Doom so I'd assume it is in Woof as well

 

Well, it's definitely not completely fixed. I noticed it was pretty bad in Epic 2, MAP26.

[bofu]

On 5/7/2024 at 5:44 PM, Devalaous said:

EDIT: Confirmed! My Cleimos 2 patch has a bit at the bottom of its Dehacked that replaces the 'met a Nazi' obituary with 'terminated by a robot', and this popped up when I was killed by the Nazi replacement

 

I'm pretty sure that one would've always worked, actually, as the WolfSS obituary was already replaceable via the DEHACKED lump. This specific fix applies to DEHEXTRA actors who use thing IDs 150-249, which have a hard-coded classname of Deh_Actor_151 ... Deh_Actor_250.

Edited May 11, 2024 by bofu

[ChopBlock223]

Does the new 14.5.0 build include the fix from here, by the way?

[ceski]

6 hours ago, ChopBlock223 said:

Does the new 14.5.0 build include the fix from here, by the way?

 

Yes.

[ceski]

On 3/7/2024 at 6:59 PM, dr.dendrite said:

Are there any plans to allow this during -shorttics recording? Now that there is a "virtual" view angle maybe you could just maintain that in high precision to give the appearance of nice smooth turning and only quantize down to 8-bits for the tic data

 

On 4/17/2024 at 1:47 PM, Trov said:

You should check out the Marathon source port 'Aleph One', it has this kind of feature built in (Marathon ALWAYS has -shorttics - esque player angle restrictions internally, but Aleph One totally decouples the camera from it)

It doesn't seem too disorienting to me, I think most people might not even notice it if nobody told them about it.

Essentially with its implementation it feels totally normal except your shots slightly align to fixed angles. It's not a 'smooth transition' between the limited angles - the camera is simply separated from them entirely.

 

I'm curious if either of you (or anyone else who wants to try it) can tell when the view angle doesn't match the true angle exactly. I added experimental "Smooth Low-Res Turning" in this test build (log in and scroll down). Launch the game with e.g. "woof.exe -shorttics" or "woof.exe -complevel vanilla -record test", and then toggle "Smooth Low-Res Turning" under "Options > General > Misc" (see example video). Does it feel good? Is it too disorienting? Please let me know what you think.

Edited May 19, 2024 by ceski
Updated test build link

[Trov]

15 hours ago, ceski said:

I'm curious if either of you (or anyone else who wants to try it) can tell when the view angle doesn't match the true angle exactly. I added experimental "Smooth Low-Res Turning" in this test build (log in and scroll down). Launch the game with e.g. "woof.exe -shorttics" or "woof.exe -complevel vanilla -record test", and then toggle "Smooth Low-Res Turning" under "Options > General > Misc" (see example video). Does it feel good? Is it too disorienting? Please let me know what you think.

Sorry, that test build is immediately closing on launch for me, without any error. I've tried a fresh config too. The stable release is launching fine.

The .com version is not producing an error message either.

Edited May 18, 2024 by Trov

[ritivob]

I noticed a graphical bug in the demo titles and HUD.

 

Spoiler

 

 

 

Edited May 18, 2024 by ritivob

[ritivob]

I also wanted a feature with a dynamic crosshair to be implemented, like in DSDA Doom, otherwise it doesn’t make much sense.

Spoiler

 

 

 

Edited May 18, 2024 by ritivob

[rfomin]

5 hours ago, Trov said:

Sorry, that test build is immediately closing on launch for me, without any error. I've tried a fresh config too. The stable release is launching fine.

 

Try to run it with "-warp 1" command line.

 

5 hours ago, ritivob said:

I noticed a graphical bug in the demo titles and HUD.

 

Thanks for the report, it will be fixed in the next version. Why did you turn off aspect ratio correction? We thought about removing this option.

 

5 hours ago, ritivob said:

I also wanted a feature with a dynamic crosshair to be implemented, like in DSDA Doom, otherwise it doesn’t make much sense.

 

I think we already have that, see Options->Status Bar/HUD->Crosshair->Lock on targert.

[ceski]

On 5/18/2024 at 1:18 AM, Trov said:

Sorry, that test build is immediately closing on launch for me, without any error. I've tried a fresh config too. The stable release is launching fine.

The .com version is not producing an error message either.

 

On 5/18/2024 at 7:24 AM, rfomin said:

Try to run it with "-warp 1" command line.

 

Try what rfomin said or download this build instead.

Edited May 19, 2024 by ceski
Updated test build link

[Trov]

18 hours ago, rfomin said:

Try to run it with "-warp 1" command line.

Oh thanks, that worked.

 

My brain doesn't really notice the mismatched angle at all unless I am specifically looking for it.

I think the only time an average person might notice is maybe when trying to shoot a very distant enemy.

 

I'll play with it turned on for a while and report back later, but for now I think it's a great feature.

 

 

I can tell that Doom's shorttics has a bigger angle increment than Marathon/Aleph One, but I think it's still fine enough to not be disorienting.

But then again, I grew up playing Descent, so my tolerance for disorientation might be higher than the average person...

Edited May 19, 2024 by Trov