Sudden STARBR2 appearance

[Memfis]

So I place STEP2 on upper part of the line. This is how it looks in Doom Builder 2: pic.
Then I load my map in prboom-plus, get to that area and guess what I see: pic. It's STARBR2! What the hell is going on?
My wad doesn't include PNAMES or TEXTURE1/2 lumps and I'm pretty sure that my doom2.wad is unmodified.

[esselfortium]

The bottom half of STEP2 is a chunk of STARBR2, it's just not that chunk of it. Here's why it happens:

Doom has a bug in which any patches who've been placed in a negative y-position in the texture will end up getting drawn as if their y-position was actually 0. STEP2 is the most noticeable instance of the bug -- it even shows pretty obviously in Doom2 MAP01 -- but a few other textures are also affected, including COMPOHSO, BROWN144, and several of the TEKWALL textures. I'm not sure how it slipped under the radar with STEP2.

ZDoom, Eternity, and presumably most other ports that modify the texture loader fix this. You could correct for it in all ports by replacing STEP2 with a single patch that's already composited together in the right way.

For that particular usage in your map, you could probably just use the actual STARBR2 texture, offset to show that part of it.

[Memfis]

Oh, I see, thanks! Amusing bug. :)

[Foxpup]

esselfortium said:

Doom has a bug in which any patches who've been placed in a negative y-position in the texture will end up getting drawn as if their y-position was actually 0. STEP2 is the most noticeable instance of the bug -- it even shows pretty obviously in Doom2 MAP01 -- but a few other textures are also affected, including COMPOHSO, BROWN144, and several of the TEKWALL textures. I'm not sure how it slipped under the radar with STEP2.

Thank you for completely destroying what remained of my sanity. I was about to ask what the Hell you were talking about, since I know for a fact that this texture displays correctly in vanilla Doom, and that negative offsets only cause problems on sky textures - they work fine on walls, and there are no texture rendering bugs in Doom 2 MAP01.

But... BUT! I noticed this was an upper texture, not a lower texture as is normally the case for STEP textures, so I decided to whip up a test map using STEP2 as an upper texture, and it does in fact display this bug in vanilla. To make sure this bug is specific to upper textures, I removed the upper texture and used STEP2 as a lower texture, and the bug is still there! So I again loaded up Doom 2 MAP01, and the bug is definitely not present in this map. It's also not present in any of my maps in which I used this texture. What's going on here? All this testing was done in DOOM2.EXE version 1.666, by the way.

[esselfortium]

Dunno. Maybe something got broken between 1.666 and 1.9, then.

[Foxpup]

Okay, I've just created a new test map from scratch, thinking that maybe some remnant of the original sidedef with the upper texture was still present somehow, and it also has the bug. In fact, no matter what I do, I am unable to construct a map in which this texture renders correctly in vanilla Doom. Which makes no damn sense because I've already made maps in which this texture works, and Doom 2 MAP01 also works. This behaviour is also identical in PrBoom+ on complevels 1 and 2 (I haven't tested other complevels as they're not really relevant, but I suspect it makes no difference anyway).

esselfortium said:

Dunno. Maybe something got broken between 1.666 and 1.9, then.

Can you post a screenshot of Doom 2 MAP01 showing this bug in vanilla Doom version 1.9? I have a suspicion that you will suddenly notice the bug is mysteriously absent, and you will find yourself wondering where (or even if) you did see it in the first place (either that or I need to find a psychiatrist).

[GreyGhost]

Foxpup said:

Can you post a screenshot of Doom 2 MAP01 showing this bug in vanilla Doom version 1.9?

Here you go, I idclipped for a better angle. Doom95 also has this bug.

(320x200 - 12k)

[Dragonsbrethren]

Foxpup said:

Can you post a screenshot of Doom 2 MAP01 showing this bug in vanilla Doom version 1.9? I have a suspicion that you will suddenly notice the bug is mysteriously absent, and you will find yourself wondering where (or even if) you did see it in the first place (either that or I need to find a psychiatrist).

[Foxpup]

GreyGhost said:

Here you go, I idclipped for a better angle. Doom95 also has this bug.

(320x200 - 12k)

D'oh! I'm an idiot. I got STEP6 and STEP2 mixed up. All cases where I thought STEP2 was working were actually STEP6. No wonder I couldn't figure out why STEP2 wasn't working. >.< Dunno where I got the idea that negative offsets work on non-sky textures, but it appears I was mistaken. This is what I get for not paying attention.

[40oz]

That's funny because until today I always thought that was STARBR2 being used as an upper texture in Entryway.

[MajorRawne]

Referring to the original images, the second one looks better anyway in my non-professional opinion :)

[Gez]

STEP2 is actually composed of two patches, so it doesn't look like STARBR2 exactly, regardless of whether the bug is fixed or not.

I wonder what part of the code is responsible for this. Doom's rendering logic is hard to follow sometimes. I think it might be this:

R_DrawColumnInCache
( column_t*	patch,
  byte*		cache,
  int		originy,
  int		cacheheight )
{
    int		count;
    int		position;
    byte*	source;
    byte*	dest;
	
    dest = (byte *)cache + 3;
	
    while (patch->topdelta != 0xff)
    {
	source = (byte *)patch + 3;
	count = patch->length;
	position = originy + patch->topdelta;

	if (position < 0)
	{
	    count += position;
	    position = 0;
	}

	if (position + count > cacheheight)
	    count = cacheheight - position;

	if (count > 0)
	    memcpy (cache + position, source, count);
		
	patch = (column_t *)(  (byte *)patch + patch->length + 4); 
    }
}

Look at the "if (position < 0) position = 0" deal. I might be completely wrong though.