What's actually going on with negative y-offsets in textures being "ignored?" (image-heavy post)

[plums]

The doomwiki article (https://doomwiki.org/wiki/Vertical_offsets_are_ignored_in_texture_patches) states:

Quote

 

Negative vertical offsets (placing the origin of the patch above the texture) are ignored, putting the top of the patch back in line with the top of the texture.

 

 

This isn't quite accurate though. Here is a wad with four textures made from TITLEPIC. (Did you know you can add any regular graphic to PNAMES and use it as a patch for a texture? The engine doesn't actually care about P_START/P_END at all.)

yoffset.wad (vanilla compatible, ZDoom based ports fix whatever bug is causing this so don't use them)

 

Texture 1 is just TITLEPIC with a negative vertical offset. As implied, the offset is ignored in game.

 

 

 

Texture 2 looks the same but there is actually a non-offset copy of the TITLEPIC patch behind it. Some of the properly offset patch shows, but not all.

 

 

 

Texture 3 was made by repeatedly pressing the "duplicate patch" button in SLADE, and then having a non-offset patch behind it, to see what would happen. I don't know that any useful information comes out of this, but it looks interesting.

 

 

 

Texture 4 is several layers of negative-offset patches.

 

 

 

 

It looks like in all cases besides the first, a bit more than half of the texture shows as it should be, and then the rest cuts off, but it's not quite the same thing happening in each texture.

 

 

As a bonus, here's a texture from @Gothic 's PatchTex.wad that uses all negative offsets and looks fine in game. It's only 128px wide though, maybe that makes a difference? But changing the TITLEPIC patch and/or the texture size doesn't seem to change things for me.

 

 

The answer lies in the code somewhere but I couldn't figure out where. Anybody know?

Edited May 25, 2024 by plums

[andrewj]

12 hours ago, plums said:

The answer lies in the code somewhere but I couldn't figure out where

I couldn't figure out what the question was....

[boris]

45 minutes ago, andrewj said:

I couldn't figure out what the question was....

 

The general consensus (and what the Doomwiki claims) is that negative patch offsets are ignored. It's a bit more complicated, though. If there are other patches in the column then the offset will still be ignored. However, in those columns it'll only draw the amount of pixels as if the vertical offset was not ignored.

 

Here's an example that probably makes it a bit clearer. On the left side is what the texture definition looks like. On the right side how it looks in-game (unless run in an engine that fixes the vertical texture offset bug).

 

 

I think the question is where in the original source this behavior can be found.

[plums]

7 hours ago, andrewj said:

I couldn't figure out what the question was....

I guess I got a bit rambly. so:

 

Why do negative vertical offsets of patches in textures behave the way they do, as shown in the example images in the first post?

 

Knowing what's going on in the source, or at least which function(s) have the problems, would be a bonus but not essential. To me it's a bit of a maze of functions for drawing columns and compositing textures anyhow.

 

 

@boris very useful image, thanks! (mirrored here on imgur since discord images never last long: https://i.imgur.com/ebOUPBa.png)

But it doesn't explain why in my screenshots above, the negative y offsets aren't ignored for part of the texture.

Edited May 26, 2024 by plums

[andrewj]

23 hours ago, boris said:

The general consensus (and what the Doomwiki claims) is that negative patch offsets are ignored. It's a bit more complicated, though. If there are other patches in the column then the offset will still be ignored

Okay, I see, thanks.

 

So this is another "quirk" (aside from Medusa) of the horrible code which composes multiple patches in a single texture column - the passed in "originy" parameter of R_DrawColumnInCache() should ignore a negative value but doesn't.

Edited May 27, 2024 by andrewj