Strange bug that only happens in PrBoom

[Zom-B]

I have some custom textures composed of existing DOOM2 patches, and one of the textures has a patch that starts at an Y coordinate less than 0. When I load it in PrBoom or PrBoom+, the patches with y<0 gets displayed as if they were saved with y=0. It displays fine in ZDoom.

I checked the TEXTURE1 lump manually and there are no errors there.

Does anyone know what is going on, if it is a PrBoom bug and if there is a workaround (other than cropping the patch and saving it in my wad)?

This was my first try:
What I saved:

What I see:


Second try.
What I saved:

What I see:


As an experiment, I used a patch shorter than the texture height. In this case the texture just gets clipped at the 4th row after being displayed at y=0.
What I saved:

What I see:

[Memfis]

Before talking about Prboom's "bugs", compare its behaviour with doom2.exe

[Gez]

Are you placing that texture on the middle part of a two-sided linedef? Your description reminds me of this.

[RjY]

Zom-B said:
I have some custom textures composed of existing DOOM2 patches, and one of the textures has a patch that starts at an Y coordinate less than 0. When I load it in PrBoom or PrBoom+, the patches with y<0 gets displayed as if they were saved with y=0. It displays fine in ZDoom.

This thing again :-)

Patches with negative y-offsets don't work in Doom. PrBoom intentionally emulates this for compatibility (it breaks several IWAD textures if you don't emulate it—ZDoom special-cases them)

I wrote a long post about it once: http://www.doomworld.com/vb/post/627938

Gez said:

Are you placing that texture on the middle part of a two-sided linedef? Your description reminds me of this.

Interesting, seems related but new

[Zom-B]

No, just lower sidedef.


I didn't know this wasn't possible in DOOM.


Thanks for the info.