This is Woof! 14.5.0 (Apr 30, 2024)

[Arsinikk]

I have two bugs to report regarding brightmaps.

1. In Hell Revealations we have a texture called 24_3PUZ2, which causes Woof to crash if we try to apply brightmaps to it. Interestingly, it works in Doom Retro which I think uses a very similar brightmaps parser. I think it's either the number or underscore that causes an issue.
2. So, this one's gonna be a bit more difficult to explain... So we've replaced some switch textures and have replaced some brightmaps on them.
   
   So let's just say the example texture is SW1STARG/SW2STARG. Now in the default Woof brghtmps.lmp in the autoload folder has this:

   TEXTURE SW1STARG REDONLY    DOOM2
   TEXTURE SW2STARG GREENONLY2 DOOM2

   But when we replaced the texture, the texture uses a different switch. Instead of the red/green switch, it's just the skull switch. And so in our PWAD brghtmps lump we set this:

   TEXTURE SW2STARG RED1 DOOM2

   The problem is that Woof hard crashes if the player sees SW1STARG in the map because it isn't defined in the PWAD brghtmps, even if we don't want that texture to use brightmaps at all. This seems kinda harsh to me, and if mapper wanted to use brightmaps, they may be confused about why Woof is crashing. I'm guessing it's reading the brghtmps.lmp file from autoload and then the brghtmps lump from the PWAD after, and I guess since SW1STARG gets defined in the autoload but not the PWAD lump, Woof just crashes.
   
   It's worth noting that Doom Retro doesn't crash if I don't include SW1STARG in the brghtmps lump, I'm guessing cuz the default brightmaps get overridden by the PWAD ones.

[rfomin]

3 hours ago, Arsinikk said:

In Hell Revealations we have a texture called 24_3PUZ2, which causes Woof to crash if we try to apply brightmaps to it. Interestingly, it works in Doom Retro which I think uses a very similar brightmaps parser. I think it's either the number or underscore that causes an issue.

 

It's not a crash, there should be error message, like this "BRGHTMPS:17:8:Expected Identifier but got Integer Constant '24' instead". We have a completely different parser. It would be much better if lump names were quoted, like this:

TEXTURE "24_3PUZ2" REDONLY

I think Doom Retro would read it anyway. Maybe it's not too late to change the spec.

 

3 hours ago, Arsinikk said:

I'm guessing it's reading the brghtmps.lmp file from autoload and then the brghtmps lump from the PWAD after, and I guess since SW1STARG gets defined in the autoload but not the PWAD lump, Woof just crashes.

 

You are probably right. Thanks for the bug report, it will be fixed.

[rfomin]

4 hours ago, Arsinikk said:

The problem is that Woof hard crashes if the player sees SW1STARG in the map because it isn't defined in the PWAD brghtmps, even if we don't want that texture to use brightmaps at all.

 

For this case, I forgot to mention that there is a NOBRIGHTMAP.

TEXTURE SW1STARG NOBRIGHTMAP

Not sure if Doom Retro support this. @bradharding What do you think?

[Arsinikk]

2 hours ago, rfomin said:

It's not a crash, there should be error message, like this "BRGHTMPS:17:8:Expected Identifier but got Integer Constant '24' instead". 

Perhaps we have different definitions of "crash". Yes it does throw an error message and then closes. Since it never enters the game (aka doesn't act as a user would expect aka start the game), I'd consider that a crash. Guess it's semantics really... -shrug-

 

2 hours ago, rfomin said:

We have a completely different parser.

ah my bad.

 

2 hours ago, rfomin said:

It would be much better if lump names were quoted, like this:

This is cool, although I would also like the old way to still work, as I have older wads that use the old (current) brghtmps format.

 

1 hour ago, rfomin said:

For this case, I forgot to mention that there is a NOBRIGHTMAP.

This is awesome. I don't think I knew about it since brightmaps isn't really documented. Mostly the way I figured out how to use it is either looking at the Woof's brghtmps.lmp or the BRGHTMPS lump in doomretro.wad. Obviously there's no reason for the NOBRIGHTMAP to be used in declaring the default brightmaps.

[rfomin]

1 hour ago, Arsinikk said:

This is cool, although I would also like the old way to still work, as I have older wads that use the old (current) brghtmps format.

 

 

Okay, I guess it's too late to change the format. There were plans to add it to Crispy and write documentation, but we got distracted by other issues. It's cool that this lump is being used, we'll fix the problems.

[bradharding]

11 hours ago, rfomin said:

 

For this case, I forgot to mention that there is a NOBRIGHTMAP.

TEXTURE SW1STARG NOBRIGHTMAP

Not sure if Doom Retro support this. @bradharding What do you think?

No, Doom Retro doesn't support this. But it shouldn't be a problem to add it in. Thanks! :)

[fabian]

On 12/7/2023 at 4:44 AM, Arsinikk said:

But when we replaced the texture, the texture uses a different switch. Instead of the red/green switch, it's just the skull switch. And so in our PWAD brghtmps lump we set this:

TEXTURE SW2STARG RED1 DOOM2

The problem is that Woof hard crashes if the player sees SW1STARG in the map because it isn't defined in the PWAD brghtmps, even if we don't want that texture to use brightmaps at all. This seems kinda harsh to me, and if mapper wanted to use brightmaps, they may be confused about why Woof is crashing. I'm guessing it's reading the brghtmps.lmp file from autoload and then the brghtmps lump from the PWAD after, and I guess since SW1STARG gets defined in the autoload but not the PWAD lump, Woof just crashes.

 

We somehow fail to reproduce this. Are you trying to assign the RED1 brightmap to the SW2STARG texture before defining that brightmap? Because assigning a different brightmap to SW2STARG in a BRGHTMPS lump while not at the same time assigning one to SW1STARG is perfectly possible.

[Arsinikk]

36 minutes ago, fabian said:

We somehow fail to reproduce this. Are you trying to assign the RED1 brightmap to the SW2STARG texture before defining that brightmap? Because assigning a different brightmap to SW2STARG in a BRGHTMPS lump while not at the same time assigning one to SW1STARG is perfectly possible.

Here's a test map. if you go down the corridor and look to the right, Woof will crash. If you press the switch in the left corridor, Woof will crash.

 

Woof-Brightmaps-Test.wad

 

This is if you include a BRGHTMPS lump that includes a SW2STARG definition, but doesn't have a SW1STARG definition. Because Woof loads the brghtmps.lmp in the autoload folder first, and then tries to load the BRGHTMPS lump in the pwad, since the autoload lmp includes SW2STARG, but the pwad lump does not, Woof gets confused and crashes.

 

I'd much rather it either stack brightmap definitions and replace the ones that are defined based on the order of brightmap definition loading, or just completely replace the brightmap definitions with the last lump loaded. The problem with how it currently loads is that a brightmap is defined from the first lump, and if the second pwad brightmaps loaded is missing any definitions from the first one, Woof crashes. Though it is possible this is only related to switches, and for some reason both SW1 and SW2 must be defined in the last brightmaps lump loaded, even though not all switch states (SW1 or SW2) have a set brightmap.

[fabian]

6 minutes ago, Arsinikk said:

This is if you include a BRGHTMPS lump that includes a SW2STARG definition, but doesn't have a SW1STARG definition. Because Woof loads the brghtmps.lmp in the autoload folder first, and then tries to load the BRGHTMPS lump in the pwad, since the autoload lmp includes SW2STARG, but the pwad lump does not, Woof gets confused and crashes.

 

Well, no. Thanks for the map, but the reason for the crash is that `brightmaps_array[]` gets reallocated in `AddBrightmap()` whereas some `elem->brightmap` are still pointing to the previous address. ;)

[Trov]

Sigil 2 is out, and it has a nonstandard sky texture width (362 px)

Woof makes it start tiling again every 256px, which cuts it off:

 

Naturally the real answer is probably "Sigil 2 shouldnt use that width for a sky texture" but since it's a fairly high profile release it might be worth considering.

Fwiw, DSDA also goofs it up but in a different way (the sky jumps around as you turn past the 360 degree threshold)

 

362px is almost 1/3rd of 1024, so it might look best to make it tile 3 times per 360 degrees.

 

I don't know if Romero can be contacted. It could at least be replaced with a 342px sky which should fit evenly 3x into 360 degrees (and does look correct in DSDA, but Woof still tiles that one every 256px)

 

GZDoom (probably what he used during development) stretches it to tile 2x every 360 degrees.

 

Until then I made a fix WAD which replaces it with a 1024px wide sky texture that tiles it 3 times. Load it after the SIGIL II wad to use it. Also works for DSDA Doom.

SIGIL_II_SKYFIX.zip

Edited December 10, 2023 by Trov

[NightFright]

I appreciate the easier setup for vanilla automap colors in latest dev builds. Importing the appropriate color scheme wasn't that hard before either, but like this it's as convenient and user-friendly as it can get. Plus I hardly think anybody would want any setup besides Boom or vanilla, anyway. Sometimes reducing options changes things to the better.

[plums]

3 minutes ago, NightFright said:

I appreciate the easier setup for vanilla automap colors in latest dev builds. Importing the appropriate color scheme wasn't that hard before either, but like this it's as convenient and user-friendly as it can get. Plus I hardly think anybody would want any setup besides Boom or vanilla, anyway. Sometimes reducing options changes things to the better.

Since you mentioned it, I slightly wish there was a "vanilla+" option that kept things like colour-coded doors. I personally don't really care though because you can still edit the config file to get whatever colours you want, and the removal of the menu options doesn't actually change custom colours that have already been set.

[NightFright]

Yeah, I guess the general idea behind this measure was rather to unclutter the menu. Those who know what they are doing can still fiddle around with the config file, so I guess it's a fair compromise.

[liPillON]

Speaking of latest devbuilds: moving the "General" menu inside the "Setup" menu now means requiring an extra step to get to video/sound/display/qol settings.

Can those 5 pages be converted to entries in the setup menu? 

[rfomin]

1 hour ago, liPillON said:

Speaking of latest devbuilds: moving the "General" menu inside the "Setup" menu now means requiring an extra step to get to video/sound/display/qol settings.

Can those 5 pages be converted to entries in the setup menu? 

 

We have plans to reorganize/simplify the menus. It's not finished yet. One of the inspirations: https://github.com/fragglet/DietBoom/blob/master/README.md

[Scorcher]

Not sure if this this is a bug or just how OpenAL works, but on MAP06 of AUGER:ZENITH, the rain ambience fades out once you jump into the alleyway. Here's a quick demo to compare with OpenAL enabled/disabled.

augerzenith_test.zip

Edited December 11, 2023 by Scorcher

[rfomin]

Small release that fixes the crash on startup of "Eviternity II RC1.wad" and the sky texture in "SIGIL_II_V1_0.wad".

 

Woof! 12.0.1 is released on Dec 12, 2023.

 

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_12.0.1/Woof-12.0.1-win32.zip

https://github.com/fabiangreffrath/woof/releases/download/woof_12.0.1/Woof-12.0.1-win64.zip

 

An AppImage for Linux is available here:

 

https://github.com/fabiangreffrath/woof/releases/download/woof_12.0.1/Woof-12.0.1-Linux.appimage

[ceski]

3 hours ago, Scorcher said:

Not sure if this this is a bug or just how OpenAL works, but on MAP06 of AUGER:ZENITH, the rain ambience fades out once you jump into the alleyway. Here's a quick demo to compare with OpenAL enabled/disabled.

augerzenith_test.zip

 

When using standard audio, things have no vertical positional audio, just like in vanilla Doom. So if an imp 1000 units above you makes a sound, it seems like it's right in front of you.

 

When using OpenAL 3D audio, things DO have vertical positional audio. So that same imp will have its pitch and volume adjusted to sound like it's far above you.

 

That's fine for typical monsters and projectiles, but what if the wad uses a bunch of clever DeHackEd tricks? For example, the rain effect in Auger Zenith is based on modified Commander Keens (it seems that you're hearing them die over and over for the rain effect). They hang from the ceiling so the rain sound fades out as you fall from the window.

 

There's no way to guess the intention of these kind of DeHackEd tricks, so use standard audio for that wad. Maybe in a future release there can be a config-only option to disable vertical positional audio, but I'll have to think about it. What do you think @rfomin @fabian ?

[Average]

Hey guys.  I've put my Sigil II WAD into my autoload folder.  It works but in the new game menu Sigil II appears BEFORE the first Sigil.  Dunno if that would be considered a bug but I thought I'd let you know anyway. :)

 

PS:  I'm using version 12.0.1 x64 build. :)

[NightFright]

If you are loading the first Sigil with the second: Don't. I seriously doubt this is supposed to be done since it would introduce at least one new gameplay element from the second part into the first, i.e. a super-tough Spider Mastermind. Which has an impact on the original episodes as well, btw. You can ofc edit the DEHACKED to undo that change, which in return makes the final fight in Sigil II a lot easier, however.

[Alaux]

4 hours ago, rfomin said:

Woof! 12.0.1 is released on Dec 12, 2023.

Excuse me, @fabian, you may want to update the thread's name accordingly.

[maxmanium]

I think the fix for Sigil II's sky may have introduced another bug. This is E3M1 from Headless Chicken; there's a garbage orange line at the bottom of the sky texture:

 

Spoiler

 

 

[rfomin]

7 hours ago, ceski said:

There's no way to guess the intention of these kind of DeHackEd tricks, so use standard audio for that wad. Maybe in a future release there can be a config-only option to disable vertical positional audio, but I'll have to think about it.

 

We have plans to create a small built-in compatibility database for popular maps, mainly to make everything playable at the default MBF21 complevel. We may also add options for audio to it.

[NightFright]

I'm pretty sure that sky image will be fixed in a future Sigil II update. Therefore I'm not even sure whether a port-sided fix was necessary on such a short notice. Maybe it should have rather been a fix solved with an additional autoload file instead of a code change. Easier to undo.

Edited December 12, 2023 by NightFright

[fabian]

8 hours ago, Alaux said:

Excuse me, @fabian, you may want to update the thread's name accordingly.

 

I've been busy with real-life stuff. Thanks to @rfomin for taking care of this release!

[ChopBlock223]

Had an idea for some future point. Light Amps are rarely used in maps because level designers don't like how 256 fullbright makes the map look bad, but what if there was an option on the sourceport end to change how they worked?

 

Rather than maxing brightness across the board, they could just raise light levels by a certain amount in any given sector, say by 64 or 96 or something, making brighter areas only somewhat brighter, while making it possible to actually see in really murky darkness.

 

No idea if there's any reasonable or easy way to implement this, but it'd make me and others want to actually put this powerup into levels.

[fabian]

Woof! 12.0.2 is released on Dec 13, 2023.

 

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_12.0.2/Woof-12.0.2-win32.zip

https://github.com/fabiangreffrath/woof/releases/download/woof_12.0.2/Woof-12.0.2-win64.zip

 

An AppImage for Linux is available here:

 

https://github.com/fabiangreffrath/woof/releases/download/woof_12.0.2/Woof-12.0.2-Linux.appimage

 

Have a lot of fun!



- Fabian

[NightFright]

Looking at the current internal developments on Github, I've seen that great strides have been made towards adding higher resolutions. This may still be far off, but I cannot emphasize enough how much I appreciate the decision to go above 400p after all. It's the only reason why I still have PrBoom+ laying around on my HDD. And it's going to be erased the day Woof gets the update. Keep going at it, guys. And thanks for continuing to make this port even "greaterer"!

[maxmanium]

Looking at the commits I see you removed the automap color settings -- why? Will it still work properly with custom palettes e.g. Ancient Aliens?

[CacoKnight]

1 hour ago, NightFright said:

This may still be far off, but I cannot emphasize enough how much I appreciate the decision to go above 400p after all. It's the only reason why I still have PrBoom+ laying around on my HDD. And it's going to be erased the day Woof gets the update.

Why not use Nugget if that's one thing you look forward to have?