Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
fabian

This is Woof! 10.2.0 (Aug 11, 2022) [Updated WinMBF]

Recommended Posts

Posted (edited)
4 hours ago, boom_compatible said:

First, is the woof 9.0.0 lowering all sectors with tag=0.

 

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".

Share this post


Link to post
Posted (edited)

International Doom even goes one step further. Besides raising gamma, you can increase general brightness of the entire level. Extremely useful for those pitch-black maps.

 

Unless this is what that new feature is about and I didn't get it.

Share this post


Link to post
Posted (edited)
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 by boom_compatible

Share this post


Link to post

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

Share this post


Link to post
Posted (edited)

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:

alt_map23.png

 

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 by NightFright

Share this post


Link to post
Posted (edited)

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.

Share this post


Link to post
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.

Share this post


Link to post
Posted (edited)

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 by NightFright

Share this post


Link to post
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).

Share this post


Link to post

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.

Share this post


Link to post
Posted (edited)

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.

Share this post


Link to post
Posted (edited)

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

Share this post


Link to post
Posted (edited)
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 by Lol 6

Share this post


Link to post

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?

Share this post


Link to post
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).

Share this post


Link to post

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.

Share this post


Link to post
Posted (edited)

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 by NightFright

Share this post


Link to post

You can only replace background tiles as flats in DEHACKED. 

Share this post


Link to post
Posted (edited)

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 by NightFright

Share this post


Link to post

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

Share this post


Link to post
Posted (edited)

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!

 

doom00.jpg

Share this post


Link to post
Posted (edited)

"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 by Delfino Furioso

Share this post


Link to post

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?

Share this post


Link to post

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.

Share this post


Link to post
Posted (edited)

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.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×