This is Woof! 14.5.0 (Apr 30, 2024)

[NightFright]

Personally, I wouldn't mind either way (regarding "426px yay or nay"). In many cases, widescreen STBAR replacements are provided in ultrawide dimensions by default. Making it just barely match specific resolutions isn't the smartest approach, no doubt. Maybe looks nice if you can see the edges on each side, but it's just cosmetics.

 

A compromise could be a statusbar stretching/scaling option in the menu. However, a "fit to screen" setting might be problematic if the bar is far wider than what you would need.

 

Other options I see, completely detached from whether it makes sense from a programmer's POV:

- Optimize it for the most frequent cases, which would be 320/426/428+ pixels (I guess)

- Implement a special case just for Unity dimensions and handle all other widths differently

 

Until now, I was either using GZDoom which always found a way to make the bar look right (even if you have to shrink/enlarge it beyond its original proportions) or ports which were limited to 400p max, so the Unity assets worked fine. 

 

PS: Hopefully this isn't going to trigger fullscreen HUD advocates. ;)

Edited December 29, 2023 by NightFright

[maxmanium]

Woof doesn't seem to be reading input from the OPTIONS lump for mapcolor_item.

 

Also, a very, very minor gripe: when you enter the setup menu, the M_SKULL is pushed some number of pixels to the left -- the menus are little bit unaligned.

Edited December 30, 2023 by maxmanium

[fabian]

1 hour ago, maxmanium said:

Woof doesn't seem to be reading input from the OPTIONS lump for mapcolor_item.

 

This config key does not exist. Do you mean "mapcolor_sprt"?

 

[maxmanium]

2 minutes ago, fabian said:

 

This config key does not exist. Do you mean "mapcolor_sprt"?

 

 

No, that's something else. This is the color of collectible items on the map with iddt x2. I guess I assumed dsda-doom and Woof would share the same automap color configs since they both derive from Boom at some point.

[fabian]

On 12/30/2023 at 10:45 PM, maxmanium said:

No, that's something else. This is the color of collectible items on the map with iddt x2. I guess I assumed dsda-doom and Woof would share the same automap color configs since they both derive from Boom at some point.

 

Sounds reasonable, this will be fixed. 

 

On 12/30/2023 at 9:23 PM, maxmanium said:

Also, a very, very minor gripe: when you enter the setup menu, the M_SKULL is pushed some number of pixels to the left -- the menus are little bit unaligned.

 

Interestingly, this dates back even to Boom 2.02. Compare the value 59 of the horizontal offset for the skull for the setup menu with the value 60 for the options menu:

 

https://github.com/Doom-Utils/historic-ports/blob/3ae2d25740b9d4ea896f0fde0c73f6b112135ce5/m_menu.c#L1725

https://github.com/Doom-Utils/historic-ports/blob/3ae2d25740b9d4ea896f0fde0c73f6b112135ce5/m_menu.c#L1070

 

Now, I cannot unsee this misalignment anymore and would like to fix it. However, I'm not sure which value is the "right" one though, as they are both original...

[plums]

In both cases the skull is the same distance from the edge of the menu item graphics (12px gap, same as with the main menu); the Setup menu text also shifts by one pixel to the right.

 

The mouse sensitivity text is aligned with the main options text, so IMO it wins by majority.

Edited January 1, 2024 by plums

[NightFright]

I wanted to use the opportunity to wish everyone, the Woof! coding team in particular, a Happy New Year. The port has made some fantastic strides forward in the last few months and this wouldn't have been possible without all those talented people involved. Most importantly, user feedback is honestly evaluated and usually finds its way into the code whenever it makes sense. Which is one of the main reasons why this port has managed to rise in popularity so quickly.

 

Thank you guys so much for your great work and efforts. Looking EXTREMELY forward to what's still in the pipeline for Woof!. I'm proudly barking along.

Edited January 1, 2024 by NightFright

[Meerschweinmann]

Hello and a happy new year.

 

I have downloaded the latest WOOF from Github before 15 minutes, and wow, what have you done?

The framerate at triple resolution boosted from 205 fps the last days to todays 267 fps.

 

Boomer.wad -timedemo demo2 , framelimiter off, vsync off, widescreen on, 16:9 display 

CPU i7 3770K.

Every run three times to get an usable average.

 

With the high video-preset the resolution seems to have a higher average resolution and more stable. Checked with the "rate cheat".

But on my 1080p 16:9 display the resolution switching was not really noticeable before and worked like a charm.

 

Thanks to all who have done this. Very good work and nice to see whats going on with Woof.

Edited January 2, 2024 by Meerschweinmann

[NightFright]

On top of that, brightmaps and colored blood now work with voxels.

[Meerschweinmann]

On 1/2/2024 at 12:20 PM, NightFright said:

On top of that, brightmaps and colored blood now work with voxels.

 

Voxels in a software rendering port alone are worth something. Colored blood and brightmaps for voxels are top class.

 

 

 

Edited March 9, 2024 by Meerschweinmann

[liPillON]

quick heads-up: since this commit

https://github.com/fabiangreffrath/woof/commit/b8677656be2826dfb281dc708113aca81136e441

 

I'm unable to run timedemos even when using the -NoSound parameter

The engine loads up, the demo get initialized, but woof "crashes" as soon as playback starts

 

no dialog/popup, just straight to desktop

generating verbose log file does not help diagnosing what's happening

 

[rfomin]

9 hours ago, liPillON said:

I'm unable to run timedemos even when using the -NoSound parameter

The engine loads up, the demo get initialized, but woof "crashes" as soon as playback starts

 

Thanks, fixed in master. 

[NightFright]

Despite vanilla color settings, I'm getting green colored lines on the automap. Happened on E4M2 of "Ultimate Doom in Name Only" when discovering the BFG secret. Seems as if these lines mark secret sectors. Is that normal/intended? (Normally shouldn't happen since green isn't part of the vanilla color scheme.)

 

Edited January 3, 2024 by NightFright

[fabian]

Automap colors for revealed secrets is a new feature and thus got is default value applied. Please re-select the vanilla colors scheme in the Automap menu to fix this. 

[NightFright]

Indeed. One should always check woof.cfg for new entries when updating dev builds. ;)

[Average]

I just tried out the latest dev build and was pleasantly surprised to see full-bright bullet puffs!  Thank @Julia Nechaevskaya for implementing that and thanks @fabian for being open to it.  You guys are so kind! :)

[NightFright]

Some bonus content for Woof! users (but should also work in Crispy and latest PrBoom+): 
Chex ultrawide statusbar with restored STARMS and ammo display! Also included: Alignment fixes for mugshot and keys.

How to install:
Place chex_fix.wad in your autoload/chex.wad and/or autoload/chex2.wad dir.

 

chex_fix.zip

Edited January 7, 2024 by NightFright

[Average]

^

Excellent stuff.  It's always nice seeing CQ getting a bit of attention. :)

[Average]

Hey guys, I think I might've found a wee glitch in the latest dev-build.  Looking up and down on a controller is really twitchy now.  I'm not sure when it changed but I just tried out the padlook function on 12.0.2 and it's perfect.  It took me a while to notice the change because I don't use it all the time.  I only use it to occasionally to look over a blind edge before dropping down.

 

PS:  Since I'm here talking about controllers, is there a possibility to have rumble added sometime in the future?  The Unity version, Eternity Engine and Doom Retro all have it and I just thought it'd be nice to have it in Woof!, too. :)

[rfomin]

15 hours ago, Average said:

Looking up and down on a controller is really twitchy now. 

 

We are changing some related code, perhaps this will be fixed soon.

 

15 hours ago, Average said:

Since I'm here talking about controllers, is there a possibility to have rumble added sometime in the future?  The Unity version, Eternity Engine and Doom Retro all have it and I just thought it'd be nice to have it in Woof!, too. :)

 

To be honest, I don't like the rumble in Unity port and Doom Retro (haven't tried it in Eternity yet). I'll try it again, and if the result is good, sure.

[Average]

Cool beans.  At least I know it's not something I've done... which is usually the case. :P

 

Thanks for taking a look at the rumble.  I get it's not for everyone but I've always enjoyed it since Quake 64.  Must be getting old. :)

[Trov]

7 hours ago, rfomin said:

To be honest, I don't like the rumble in Unity port and Doom Retro (haven't tried it in Eternity yet). I'll try it again, and if the result is good, sure.

The Unity port's problem is that the rumble starts as soon as you click rather than when most guns fire ~7 tics later.

It would probably feel a lot better if that were fixed (doing the rumble with the gunshot instead)

[ChopBlock223]

Writing up an intermission text, I make sure that it fits, and it does, until I test it in 4:3 and it doesn't. I guess this is on me, and a "widescreen-ism".

 

I realize that fixing this would probably call for implementing a new type of text intermission entirely (and in that case, probably as part of an all new complevel), so I'll just have to deal with it for now.

 

However, assuming that the UMAPINFO standard gets some updates some day, wouldn't it be theoretically possible to devise a style of text screen which automatically formats the text for screen sizes, and if needed can be scrolled up and down by the user in case it's longer than expected?

 

This isn't directly related to Woof, at least at present, I just want to know from experienced port devs if this is a worthwhile/realistic proposition, if that theoretical day ever comes.

[fabian]

With "intermission text", do you mean the story telling text screens that appear at the end of an episode? Or do you mean the Finished / Now Entering screens showing the map names at the end of a level? Because for the former the text lines are fit into the non-widescreen area of the screen.

[ChopBlock223]

I mean the storytelling screens.

 

Fundamentally, I think that it could be made to handle the same, like if you don't care about the story or you're recording a multiple level speedrun, you can just hit the use key once and all the text is revealed right away, and hitting it again moves on to the next level.

 

The only functional difference would be that if all the text on a row doesn't fit on the given screen, it gets shifted to the next row, with any text not fitting on that row getting shifted to the next, and so on. Then, the user could use their scroll wheel or arrow keys to move the rows up and down to read it (or as said, hit use two times to skip).

Possibly also the option to assign a specific .MIDI/music file for any such screen.

 

Again, NOT a direct request for Woof, just asking if such a thing could be cleanly implemented as a cross port standard in some indeterminate future. Perhaps if there's ever an MBF25, along with improvements to UMAPINFO.

Edited January 15, 2024 by ChopBlock223

[NightFright]

You just need to remember the max amount of characters you can use to keep it compatible. The longest line in D2 is 43 chars (IIRC) and that's my personal limit when I compose such texts.

Edited January 15, 2024 by NightFright

[ChopBlock223]

Just now, NightFright said:

You just need to remember the max amount of characters you can use to keep it compatible. The longest line in D2 is 43 chars (IIRC) and that's my personal limit when I compose such texts.

Sure, I can do that, but when 16:9 actually allows for (comparatively) more text, it's kind of annoying that it just gets cut off for people playing in 4:3.

 

It's a pretty small issue overall, but when the text isn't even that long anyway (in my case, it's usually about 40% to 50% which gets cut off), it's frustrating, and it feels like I'm leaving 4:3 players out in the rain.

[pantheon]

For what it's worth, "You need a yellow key to activate this object" gets cut off in 4:3 too. Next time I make a build, I'll go with "You need a yellow key for this object" etc. Seems like it's changeable in d_englsh.h.

[fabian]

12 hours ago, pantheon said:

For what it's worth, "You need a yellow key to activate this object" gets cut off in 4:3 too. Next time I make a build, I'll go with "You need a yellow key for this object" etc. Seems like it's changeable in d_englsh.h.

 

This should work, though. I am testing line length against an unnecessary margin value. This is fixed now.

[NightFright]

I've had the chance to test the rewind feature more thoroughly in Nugget Doom (which took it from DSDA-Doom). Gotta say it's really, really neat. Basically it reduces the need to reload your game to almost zero. You screw up, rewind, try again.

 

It's less about saving time (if you deactivate the quicksave/quickload message) since loading your last game is almost instant, but rather for those cases when you didn't save for a while and don't want to lose too much of your progress.

 

Is there anything which prevents this from being implemented here as well? Maybe constantly recording a short part of the game (the last 60 keyframes by default) takes some toll regarding performance or something? (Couldn't say I noticed, though.) To some degree it might also turn gameplay even more into mere trial-n-error, but the same could be said about saving/loading your game in general.

 

(I'm aware it should rather be avoided to copy too much from other ports and avoid feature creeping, but I got to acknowledge a good idea when I see one.)

Edited January 19, 2024 by NightFright