This is Woof! 14.5.0 (Apr 30, 2024)

[boom_compatible]

On 5/12/2022 at 5:02 PM, fabian said:

 

If you got to the Options -> Setup -> Doom Compatibility menu and on the second page set "Linedef effects work with sector tag = 0" to "Yes", does this fix the issue for you?

 

Edit: No, it doesn't. What you are looking for is PrBoom+'s "LINEDEFS W/O TAGS APPLY LOCALLY" which is listed in section "COMPATIBILITY WITH COMMON MAPPING ERRORS".

 

Thanks for the clarification!

 

I thought comperr_zerotag was the same thing as comp_zerotags. My bad!

 

Because woof have only comp_zerotags and dsda have only comperr_zerotag.

 

Sorry for the noise o/

Edited May 16, 2022 by boom_compatible

[NightFright]

They are trying to get brightmaps working on Github now btw, possibly with a method used in GZDoom. Fingers crossed!

[NightFright]

I am currently playing A.L.T. and have a showstopper issue in MAP23 ("God Is Dead"). When calling down an elevator, I cannot pass on top across it once it is down, preventing me from getting into the corridor behind it. I tried it with latest versions of Woof, Crispy Doom, PrBoom+, GZDoom. Only the last one allowed me to pass to the other side, but none of the others. I am running this with -complevel 2 (as intended).

 

Screenshot of the affected passage:

 

Curious fact: When noclipping to the other side and turning clipping back on, I can enter the elevator in Crispy, Woof and PrBoom+. In GZDoom it's the opposite (can cross without cheats, but then not from the other side).

Edited May 17, 2022 by NightFright

[rfomin]

Your version of A.L.T. from idgames? There is a newer version on DSDA https://dsdarchive.com/wads/alt_2012-12

[NightFright]

On the title screen it says v1.2, dunno if that's the latest one. But DSDA archive version is identical to the one on idgames, so I guess it's the one I have.

Edited May 17, 2022 by NightFright

[rfomin]

It's different, version on idgames https://www.doomworld.com/idgames/levels/doom2/Ports/megawads/alt dated 2012-05, on DSDA it's 2012-12 (file size is different too) see https://doomwiki.org/wiki/A.L.T.#External_links

[rzh]

1 hour ago, NightFright said:

I am currently playing A.L.T. and have a showstopper issue in MAP23 ("God Is Dead"). When calling down an elevator, I cannot pass on top across it once it is down, preventing me from getting into the corridor behind it. I tried it with latest versions of Woof, Crispy Doom, PrBoom+, GZDoom. Only the last one allowed me to pass to the other side, but none of the others. I am running this with -complevel 2 (as intended).

IIRC, Sacrament, the other WAD made by the same people is also listed as a limit-removing WAD, but some features are broken unless you use complevel 9.

There are a few WADs like that.

[NightFright]

Using the DSDA version didn't make a difference, but changing complevel from 2 to 9 did. They should have been a bit more specific in their readme file, then. Anyway, then it's not a bug. Guess in GZDoom it worked only because there I have compatmode set to "Default" (which is something about MBF mode, if I am not mistaken). So, thanks for the hint (also with Sacrament, for I intended to play that one next)!

Edited May 17, 2022 by NightFright

[rzh]

11 minutes ago, NightFright said:

Using the DSDA version didn't make a difference, but changing complevel from 2 to 9 did. They should have been a bit more specific in their readme file, then. Anyway, then it's not a bug. Guess in GZDoom it worked only because I have compatmode set to "Default", there (which is something about MBF mode, if I am not mistaken). So, thanks for the hint (also with Sacrament, for I intended to play that one next)!

Yeah, I guess it was an oversight most likely caused by the age of the WAD.

Since this is around 2012, I don't think there were any non-Boom based ports that could play limit-removing WADs.

Maybe the mapper(s) didn't know about complevels, maybe they built the map in Boom mode assuming it's the same thing as limit-removing (it is a bit hard at first to realize that complevel 2 doesn't have the same limitations as DOS Doom).

[NightFright]

At least in the Sacrament readme they recommend using PrBoom+, which gives you some hint that it could be a cl9 project. They didn't do that in A.L.T., though.

[banjiepixel]

It is pretty safe to assume that many, maybe even most, "limit removing" maps released before Crispy Doom probably are not actually limit removing. Unless the readme mentions the actual complevel of course.

Edited May 17, 2022 by banjiepixel

[NightFright]

So basically "Limit Removing" before 2014 actually meant "Boom compatible". Will try to keep that in mind.

Edited May 17, 2022 by NightFright

[xX_Lol6_Xx]

8 hours ago, NightFright said:

Guess in GZDoom it worked only because there I have compatmode set to "Default" (which is something about MBF mode, if I am not mistaken).

GZDoom does have a compat mode to MBF and Strict MBF. But like with all the other compatmodes, it fixes some issued that, as far as I know, can't be turned on with the compatibility options

Spoiler

Edit: Just clarifying, my intention was to complement the post, please don't take it as an offense or something :-)

 

Edited May 17, 2022 by Lol 6

[NightFright]

When looking at large patches of textures with repetitive patterns, e.g. brickwalls, one would encounter considerable Moiré effects. My guess is this happens due to low resolution. Besides implementing higher resolutions, is there anything that could be done to reduce these visual distortions?

[Shepardus]

3 hours ago, NightFright said:

When looking at large patches of textures with repetitive patterns, e.g. brickwalls, one would encounter considerable Moiré effects. My guess is this happens due to low resolution. Besides implementing higher resolutions, is there anything that could be done to reduce these visual distortions?

That happens at higher resolutions too. What you need is anisotropic filtering, which you can find in hardware renderers such as PrBoom+/dsda-doom's and GZDoom's (note that for anisotropic filtering to do anything you have to enable texture filtering too, use "nearest mipmap" or "linear mipmap" if you prefer blocky pixels).

[Woolie Wool]

I think with retro ports like Woof the moiré should be embraced as a quirk of the original renderer. Imperfections, weird edge cases, and shortcuts, and the aesthetics those things produce, is the whole point of running a software renderer, especially at low resolution. If you want perfection, run Eternity or DSDA in GL mode.

[NightFright]

Something else that might be worth looking into:
Custom intermission backgrounds don't seem to work properly, neither via DEHACKED nor UMAPINFO. I noticed this with my custom DEHACKED/UMAPINFO I made for "Icarus: Alien Vanguard". To be sure I didn't make any mistake, I checked with -complevel 2 (which should be enough) or -complevel 9, no mods loaded.

 

Notes:

- DEHACKED and UMAPINFO have been embedded into the PWAD.

- Level name replacements work, it's just the intermission backgrounds that cause issues.

- The textures specified as background tiles are not defined as flats, but patches (not within the FF_START/FF_END markers). If I choose an entry from there, it works.

 

DEHACKED:

[STRINGS]
BGFLAT06 = IIWWEAV8

UMAPINFO:

MAP MAP06
{
	interbackdrop = "IIWWEAV8"
}

 

Tested ports:

- Crispy: Covers entire screen, but tile is distorted
- PrBoom+: Tile is not covering full screen and is aligned to top left corner
- Woof: Tile either not used at all, uses sky background instead (DEHACKED) or centered w/o covering full screen (UMAPINFO)
- GZDoom: Works as intended

 

 

Edited May 18, 2022 by NightFright

[fabian]

You can only replace background tiles as flats in DEHACKED. 

[NightFright]

Alright, then I guess GZDoom is the only port that doesn't care. Will have to find a way to work around that, then.

Anyway, in UMAPINFO, the non-flat textures would also not be properly aligned. Unless that one isn't supposed to support non-flats, either.

Edited May 18, 2022 by NightFright

[fabian]

It supports non-flats, i.e. patches, and draws them horizontally centered. However, it draws them in their original size, no stretching is applied. 

[NightFright]

And no tiling either, I guess. Well, then it all works as intended.

 

BTW, thanks for implementing brightmaps (see attached screenshot)! Looks like it works just as smoothly as it does in Crispy. One big visual feature done on my wishlist!

 

Edited May 18, 2022 by NightFright

[liPillON]

"textures and sprites" means that no monsters are affected, right?

I've tried the feature out and I'm not seeing any glowing eyes, nor light-emitting caco's mouths

 

I'm not complaining, just trying to catch the differences - even the subtler ones..

maybe I'm just used to brightmap+ on gzdoom..

Edited May 18, 2022 by Delfino Furioso

[fabian]

@Delfino Furioso Yes, right. 

[NightFright]

I never noticed Crispy didn't have monster brightmaps. Didn't miss them that much, tbh. Is that why you are trying to get png brightmaps into the port since monsters are otherwise not doable?

[Average]

@fabian, I have a couple of small feature suggestions.  Would you mind if I posted them here?

[rzh]

I noticed that the rocket launcher's recoil feels wrong, it seems to be desynced from the actaul rate of fire, and instead of shaking the camera when fired, it's shaking it constantly, maybe 3-4 times for each rocket shot.

Apart from that, this port becomes better and better and it was already my favourite port.

All I need is that truecolor rendering and I can die happy.

[NightFright]

Time to make a Github request soon, considering how fast some requests go through... However, I think truecolor isn't a simple thing to pull off. Even though it works pretty much 100% in Crispy by now.

Edited May 18, 2022 by NightFright

[fabian]

3 hours ago, NightFright said:

I never noticed Crispy didn't have monster brightmaps. Didn't miss them that much, tbh.

 

In Crispy, and now in Woof!, brightmaps are applied by pixel color value, and not by pixel position. Thus, it is impossible to e.g. light up the blue pixels in a Cacodemon's mouth without also lighting up all the other pixels of the exact same color in that sprite at the same time. 

 

3 hours ago, NightFright said:

Is that why you are trying to get png brightmaps into the port since monsters are otherwise not doable?

 

We are not seriously trying to get this implemented - at least I am not - at least not now. 

 

2 hours ago, Average said:

@fabian, I have a couple of small feature suggestions.  Would you mind if I posted them here?

 

Of course, please post them here or over at the github tracker. 

[NightFright]

Actually the GZDoom brightmaps system is not very flexible. With your approach you even manage to have brightmaps on the fly for textures and sprites from pwads. No need to manually create brightmaps for anything. If it stays like that, it's good enough for me.

Edited May 18, 2022 by NightFright

[Average]

@fabian,  cool beans.

 

The first suggestion would be an option to centre messages along the top of the screen.  It's always been a bugbear of mine that messages in Doom are defaulted to the top left.  I enjoy the messages but find it distracting to move my eyes from the centre third of the screen.  It'd also look tidier when the 'Secret' message pops up dead centre while other messages are rattling by in the corner.

 

The second suggestion is another 'small' thing that drives me crazy.  At the end of a level the stats 'count up' with the gun sound firing rapidly.  It takes ages, the sound is annoying and I'm sure I'm not the only one who just hits fire and skips the count up anyway.  My suggestion would be an option to simulate hitting the 'fire' button to instantly present the stats with a single bang.  I just think it would make the screen feel a little slicker.

 

I know they're not the kinda things that are high priority for most but I always appreciate small QoL options.

 

No worries if the suggestions aren't anything you'd be interested in adding. :)