This is Woof! 14.3.0 (Mar 15, 2024)

[fabian]

3 hours ago, Woolie Wool said:

Avactor now runs almost perfectly in Woof, except that it doesn't load IWAD textures that are used for locked door markers, for instance on map01:

 

Hm, works for me:

 

 

Also, why is your Automap green and mine isn't?

 

3 hours ago, Woolie Wool said:

In addition, there were alignment errors on the chains in the main arena of map05:

 

The chains show the same alignment glitches in Crispy, so apparently this isn't anything that I have encountered before. Any hints?

 

3 hours ago, Woolie Wool said:

In addition, tutti-frutti like behavior with certain textures like the sky in Eviternity map26 (the opening lift now looks fine) still exis

 

Same here. the sky texture seems to have "wrong" height.

[plums]

11 hours ago, fabian said:

The chains show the same alignment glitches in Crispy, so apparently this isn't anything that I have encountered before. Any hints?

The texture (and the patch it's made from) are 672 pixels long. But it looks like it's only displaying the first 512 before repeating.

Edited June 12, 2020 by plums

[Woolie Wool]

8 hours ago, fabian said:

 

Hm, works for me:

 

 

Also, why is your Automap green and mine isn't?

 

 

The chains show the same alignment glitches in Crispy, so apparently this isn't anything that I have encountered before. Any hints?

 

 

Same here. the sky texture seems to have "wrong" height.

My automap is green because the automap colors are configurable in MBF and I set them to match my ZDoom colors.

 

Here is what the chains look like in GZDoom and PrBoom+:

 

As for the HOM key texture glitch, is that with the 1.2.2 Windows release build? For all I know it could be platform-specific.

[Woolie Wool]

Saw this error with some of the scrolling textures in map06. There is definitely some texture size limit at play:

 

 

EDIT: There is a showstopping bug in map09 of Avactor, where the multistage crusher/monster closer trap gets stuck just before the final stage:

Edited June 13, 2020 by Woolie Wool

[fabian]

On 6/12/2020 at 11:44 AM, plums said:

The texture (and the patch it's made from) are 672 pixels long. But it looks like it's only displaying the first 512 before repeating.

 

There is a comment in r_data.c:R_GenerateLookup() stating that textures taller than 256 are supposed to be single-sided. Maybe that's somehow related, but I am not sure, to be honest.

 

On 6/12/2020 at 6:01 PM, Woolie Wool said:

My automap is green because the automap colors are configurable in MBF and I set them to match my ZDoom colors.

 

Ah, okay. If you post screenshots of the Automap - which is very helpful and appreciated, next time please make sure to add a marker where you currently stand. It's quite hard to figure out the player arrow in the pixel mess. ;)

 

On 6/12/2020 at 6:01 PM, Woolie Wool said:

As for the HOM key texture glitch, is that with the 1.2.2 Windows release build? For all I know it could be platform-specific.

 

Yes, probably. Is anything printed to stderr if you start the game from a terminal?

 

On 6/12/2020 at 10:37 PM, Woolie Wool said:

Saw this error with some of the scrolling textures in map06. There is definitely some texture size limit at play:

 

Hm, how wide is the texture in question here?

 

On 6/12/2020 at 10:37 PM, Woolie Wool said:

EDIT: There is a showstopping bug in map09 of Avactor, where the multistage crusher/monster closer trap gets stuck just before the final stage:

 

I hope you understand that I am not going to change game mechanics away from MBF, even if this may cause some specific maps to lock up. Is this reproducible?

[plums]

re: The chain, I think the issue is non-power of two textures.

 

Here's a demo map.

longtex.zip

 

The wall with the torch is a texture that's 666px long but made of patches 512px long. (the numbers on all the walls are the patch size, not the texture size.) You never see the end of the texture in woof (blue line).

 

The wall that says 666 is a texture that's 1024px long but made of patches that are 666px long. You do see the end of the texture (blue line).

 

The wall that says 1024 is a patch/texture that is 1024px long, you see the end of the texture.

 

But here's what's weird: With this demo in PrBoom+, you see the same thing as in Woof in software mode, but always see the end of the non-po2 texture in GL mode. BUT, in software mode PrB+ still shows avactor's chains properly. So I don't know what's going on there at all. It might have something to do with the chains being 2-sided?

 

edit: Yeah PrB+ will always display the 2-sided wall properly, even in software mode. Woof does not.

longtex2.zip

Edited June 15, 2020 by plums

[fabian]

This should be due to texturewidthmask[]:

https://github.com/fabiangreffrath/woof/blob/master/Source/r_data.c#L633

https://github.com/fabiangreffrath/woof/blob/master/Source/r_data.c#L450

 

And PrBoom+ showing the scrolling texture properly may be due to this fix:

https://github.com/coelckers/prboom-plus/blob/master/prboom2/src/r_data.c#L104

 

[fabian]

So, PrBoom+ has a function called R_GetPatchColumnWrapped() that is uses for drawing masked segs, i.e. mid-textures. 

https://github.com/coelckers/prboom-plus/blob/master/prboom2/src/r_patch.c#L960

 

This functions uses the modulo operator instead of texturewidthmask to map the requested column index into the texture's width range. Using this should fix the issue with the chains in MAP05. Forcing the requested column index to be non-negative might fix the scrolling texture issue in MAP09 (btw, where exactly can this be found?).

 

Regarding the missing texture on the pillars in MAP01, it is really important to know if anything useful is written to the terminal when this map is loaded.

[plums]

Sorry if I missed it, but is there a way to emulate Boom behaviour with Woof? I just played a map where the scroller behaviour doesn't work properly in MBF (including PrB+ -complevel 11) but does work in Boom. Also is there a list of/way to show command-line params, other then grepping through the source?

[fabian]

6 hours ago, plums said:

Sorry if I missed it, but is there a way to emulate Boom behaviour with Woof? I just played a map where the scroller behaviour doesn't work properly in MBF (including PrB+ -complevel 11) but does work in Boom.

 

This question aims into the same direction as https://github.com/fabiangreffrath/woof/issues/64

 

Short answer: Yes, there is a Boom compatibility mode in MBF, but it is very very flawed. That is, it was very very flawed, now it is only very flawed, because I had the chance to fix some issues. However, this mode is only enabled when playing back Boom demos. It is currently not possible to enable this mode by other means, i.e. to start a new game or record a demo in Boom compatibility mode. And, I will not add this until I have full confidence in the actual compatibility of the Boom compatibility mode.

 

Edit: This https://github.com/fabiangreffrath/woof/issues/64#issuecomment-599488065

 

Quote

Also is there a list of/way to show command-line params, other then grepping through the source?

 

No, unfortunately not. This project is clearly lacking some documentation, as @wesleyjohnson has already pointed out earlier.

[fabian]

On 6/15/2020 at 3:55 PM, fabian said:

Forcing the requested column index to be non-negative might fix the scrolling texture issue in MAP09 (btw, where exactly can this be found?).

 

@Woolie Wool ?

 

On 6/15/2020 at 3:55 PM, fabian said:

Regarding the missing texture on the pillars in MAP01, it is really important to know if anything useful is written to the terminal when this map is loaded.

 

@Woolie Wool ?

[Woolie Wool]

Nothing is written to the terminal when map01 is loaded, but back in 1.2.1 it would report missing textures related to keys (DOORRED*, DOORBLU*, DOORYEL*) before crashing.

 

The scrolling texture is in map06 and can be found at:

 

[fabian]

15 minutes ago, Woolie Wool said:

Nothing is written to the terminal when map01 is loaded, but back in 1.2.1 it would report missing textures related to keys (DOORRED*, DOORBLU*, DOORYEL*) before crashing.

 

Nothing?! I mean, I just converted the fatal error message into a warning, so it should be printed at the exact same time as before. Could you probably post the entire terminal output somewhere?

 

15 minutes ago, Woolie Wool said:

The scrolling texture is in map06 and can be found at:

 

Thanks, I'll have a look!

[Woolie Wool]

I cannot because there is no stdout.txt or other log produced.

[plums]

On 6/12/2020 at 4:37 PM, Woolie Wool said:

There is a showstopping bug in map09 of Avactor, where the multistage crusher/monster closer trap gets stuck just before the final stage:

Does this also happen in PrBoom+ with -complevel 11? As I recently discovered there are some differences in the way Boom handles scrollers compared to MBF which can affect voodoo doll setups.

[fabian]

1 hour ago, Woolie Wool said:

I cannot because there is no stdout.txt or other log produced.

 

Oh, somehow I was under the impression that you were running an ARM system and thus a non-Windows OS with proper stdout/stderr. 

[fabian]

Strange, I just had the opportunity to check with a 32-bit Windows binary and I cannot reproduce any of the later issues that you reported, neither the scrolling textures on MAP06 nor the missing blue skull textures on MAP01.

 

Could anybody else please confirm?

[wrkq]

On 6/18/2020 at 5:27 PM, fabian said:

Oh, somehow I was under the impression that you were running an ARM system and thus a non-Windows OS with proper stdout/stderr.  

 

If you start the program from CMD window or batch file with a redirect like:

woof.exe -params -here >stdout.txt 2>stderr.txt

or from a batch file with the "same folder as the batch" marker:

woof.exe -params -here >%~dp0\stdout.txt 2>%~dp0\stderr.txt

 

it should properly redirect stdout/stderr to these files even when the executable's header does not have the "attach a console on startup" flag and thus does not print anything to a visible console (popup or CMD) normally.

[Woolie Wool]

Found a bug with Obsidian's Candlemass for Boom-compatible ports. At a distance, looking out one of the windows will present some sort of midtexture clipping error, shown in the screenshots. The lift across from the window in the same hallway (not pictured) also has some issues.

 

 

Here is the window where the problem with the outside view appears. Turning around at this spot and going down the corridor will reveal the problematic lift.

 

 

The same view in PrBoom 2.5.0.

[fabian]

This is not the usual midtexture-not-pow-of-2 bug. I see the same glitch in Crispy - Choco and MBF.exe won't even load the map. So, again, this is a map declared as "Boom-compatible" but apparently only tested in PrBoom+ -complevel 9 - which is *not* the same as Boom.exe.

[fabian]

On 6/21/2020 at 2:57 AM, Woolie Wool said:

looking out one of the windows will present some sort of midtexture clipping error, shown in the screenshots

 

I don't understand the issue, but I am a mapping dyslexic anyway. There are three sectors (203, 204, 208) with the exact same floor and ceiling heights. These sectors are separated by linedefs 904 and 923 which both have BSQUARE as their mid-texture. BSQUARE, according to the TEXTURE1 file, is a 64x64 texture consisting only of the ALLBLACK patch, i.e. it's an all-black texture.

 

In the "buggy" screenshot the window is renderd all-black except for a translucent stripe at the bottom, whereas in the "correct" screenshot from PrBoom+ only the upper part of the opening is rendered black. How is that possible?

[andrewj]

2 hours ago, fabian said:

n the "buggy" screenshot the window is renderd all-black except for a translucent stripe at the bottom, whereas in the "correct" screenshot from PrBoom+ only the upper part of the opening is rendered black. How is that possible?

The lower unpeg flag is clear, and Y offset is 56, so the texture is pushed up a fair way relative to the floor.

[fabian]

Alright, got it! The texture contains only a single patch, so it does not need to get composed by R_GenerateComposite(). Instead, its columns are taken directly from the patch - which in turn is 128 px high instead of the 64 px that the texture is supposed to be.

 

https://github.com/fabiangreffrath/woof/blob/master/Source/r_data.c#L450

 

As so often in Doom, having found the cause for an issue doesn't mean it is easy to fix it. ;) [Note to myself: I would have to generate two sets of composited textures and column offsets, one for mid-texture rendering on two-sided lines and one for opaque one-sided lines. I'll probably try to get this fixed in Crispy first - some day, maybe...]

 

Please note that this is not a bug or a random engine limitation. This is how Doom works! This is how the rendering of textures in Doom works.

Edited June 22, 2020 by fabian

[fabian]

On 6/19/2020 at 12:15 PM, fabian said:

I cannot reproduce any of the earlier issues that you reported, neither the scrolling textures on MAP06 nor the missing blue skull textures on MAP01.

 

@Woolie Wool Still unable to reproduce this. Are we using the same version of Avactor.wad? Mine is exactly 134.409.789 Bytes. And are you sure your copy of Doom2.wad is unmodified?

[Woolie Wool]

It seems like my copy of Avactor was an earlier build than the latest one, changing it to the "update 3" in Eradrop's thread fixes the problem with the key textures. The scrolling texture seen in my video, though, I can't find it now, because it's used only once in the entire map (which is enormous) and in a very out of the way place. The scrolling texture with a problem is a conveyor belt with chainguns on it.

[fabian]

10 minutes ago, Woolie Wool said:

It seems like my copy of Avactor was an earlier build than the latest one, changing it to the "update 3" in Eradrop's thread fixes the problem with the key textures.

 

That's good to know, thanks! 

 

10 minutes ago, Woolie Wool said:

The scrolling texture seen in my video, though, I can't find it now, because it's used only once in the entire map (which is enormous) and in a very out of the way place. The scrolling texture with a problem is a conveyor belt with chainguns on it.

 

You posted the exact position earlier in this thread on Jun 18. 

[Woolie Wool]

So I did. Checked, the bug is gone in the final release build of avactor.wad. The key texture bug in the earlier wad was really strange because it affected Woof but not ZDoom.

[fabian]

Okay, so at least two of the issues that you reported earlier can be attributed to the WAD itself and not to engine bugs. 

[fabian]

I have just released Woof! 2.0.0:

• Support for uncapped rendering frame rate with frame interpolation has been added.
• A char-signedness issue has been fixed.

https://github.com/fabiangreffrath/woof/releases/download/woof_2.0.0/Woof-2.0.0-win32.zip

[Woolie Wool]

This tutti-frutti-like band still appears in the sky in Eviternity map26, and the issues with the chains being cut off in Avactor map05 mentioned upthread still persist. I'm guessing these have to do with odd texture sizes?