Distorted Texture

I'm not sure what I did wrong here, but my texture looks different in prboom than it looks like in SlumpEd, XWE, and Doombuilder 2.



This is what the texture is SUPPOSED to look like

I checked the dimensions of the texture, I deleted the patch and imported it a second time, yielding the same results. How can I get around this? None of my other textures have given me the same problems.

Does it look correctly in Eternity and ZDoom? (Eternity has a different renderer, and ZDoom has a different texture manager.) And how about GLBoom+?

Heck, how about if the sector it's in has brightness 255?

I noticed a similar problem with doom97.wad a couple of days ago which I reported on the issue tracker.
Anyway, I had some time spare so I thought I'd have a quick look at this.
Note: The following is from prBoom+ 2505 it may have changed since.
I may be wrong but there appears to be a bug in r_patch.c : createTextureCompositePatch Line 685

	// do the buggy clipping
	if((oy + top) < 0)
	{
		/* Original
		count += oy;
		oy = 0;
		*/

		count += (oy + top);
		top += oy;
		oy = 0;
	}

I also had a quick look at r_data.c : R_DrawColumnInCache Line 204 to try and see what the comment was referring to but I can't see anything wrong with that version.

Anyway hope this helps.

4mer said:

Note: The following is from prBoom+ 2505 it may have changed since.
I may be wrong but there appears to be a bug in r_patch.c : createTextureCompositePatch Line 685

	// do the buggy clipping
	if((oy + top) < 0)
	{
		/* Original
		count += oy;
		oy = 0;
		*/

		count += (oy + top);
		top += oy;
		oy = 0;
	}

Those are for tall patches. It doesn't seem very likely to me it would be the issue here. Though if so, then (G)ZDoom, SLADE3, the very latest SVN builds of DB2, and probably Eternity though I haven't checked that one, would all show the same thing as PrBoom+.

So yeah I guess what I'm saying is compare with the aforementioned utilities.

The brightness in that sector is 192. I've also used the same texture in other locations of varying light levels and it still looks the same. I don't have all those source ports installed, I do however, have ZDoom, and it looks fine:



But it's important to me that it looks like it is supposed to in all source ports it's compatible with :/

I could try deleting it's entry in the TEXTURE1 and PNAMES lump and reenter it. Hopefully that works.

Did you try fullbright? Maybe some of that pink turns into grey at lesser light levels. And ZDoom won't prove it, because it doesn't use the default COLORMAP, which is known for turning red into brown or grey at dark levels of light.

Would you like me to take multiple screenshots of me looking at the light from varying angles, distances, and light levels? I'm certain it's not the lighting. There's something wrong with the texture. I had a similar problem with a texture once before, i found out I made the dimensions 128x65 by mistake, and correcting its attributes fixed the problem, but I can't seem to figure out what's wrong here.

How about posting the texture? That way others can have a look.

Yeah, but it's dangerous: I might decide to scavenge it for my work :)

http://img832.imageshack.us/img832/8997/urwall11.png

Shall I laugh or not?

How am I supposed to check it if it's not in any usable form. I'll need the patches and the texture definition in WAD form to see if maybe something is wrong with it. Just posting an image of it won't help you.

That is the patch. I literally imported that raw data as a doom graphic and imported it in a wad (except that imageshack.us turned it into a .png instead of a .bmp as it once was) If that's the case then I'll have to fix it myself. Thanks for the help anyway :/

With what utility? XWE? Slumped? Wintex? Something else? "Import raw data" is XWE parlance for "import without converting", so "import raw data as doom graphic" is a contradiction in terms.

Well, if I can't check the exact patch that's causing you problems I doubt this can be resolved.

I used slumped. I imported the image as a lump, used Slumped to convert it to a doom graphic, then added it PNAMES, then added it to TEXTURE1, as I did with the rest of the textures.

The problem I have seen occurs when the first post of a column starts with y < 0 for a patch that is not the first in a texture (composite) and looks wrong when yorigin + topdelta < 0.

i.e. Someone has made a patch that has a margin of blank space around it and then placed the patch in the texture with a -ve offset larger than topdelta (not a regular occurence).

Comparing the ports it seems that:

ZDoom, GZDoom and Doomsday display what you would expect to see as per the definition of the texture.
Choc Doom, Eternity, prBoom202 and Edge display the same as Doom2 v1.9 a distorted texture which is probably the clipping bug mentioned in the prBoom-Plus source code.
But prBoom-plus 2507 and glBoom-plus 2507 display a different distortion.

Note: This may be a different problem to what 40oz has shown (if his texture is a single patch).

I have uploaded a wad and some comparison screen shots here:
http://files.drdteam.org/index.php/files/get/2hDm1VE0p8/patch-comparison.zip