[Fixed] Texture bug.

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Post Reply
User avatar
Espi
... in rememberance ...
Posts: 55
Joined: Thu Jul 17, 2003 6:51 am
Location: Finland
Contact:

Texture bug.

Post by Espi »

There's something wrong with how ZDoom displays the BIGDOOR7 texture with doom.wad:
Image
This doesn't happen with doom2.wad nor with doom.exe/doom2.exe.
User avatar
Enjay
 
 
Posts: 26537
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland
Contact:

Post by Enjay »

As you say, it only happens with Doom.wad. Doom2.wad is fine. BIGDOOR7 is an odd one. The patches in it are 136 tall but the texture is 128. I looked into the texture lumps of the 2 wads, and found a difference.

In Doom2, the patch W105_1 is used twice at these offsets:

-5, 0 and 123, 0

In Doom (Ultimate), the offsets are:

-4,-4 and 124, -4

So, rather oddly, the texture is set up differently in Doom1 and Doom2. Because of the offsets, I would expect the bottom 4 pixels of that odd bit of the W105_1 patch to be visible in Doom1 when the texture was used on a door (ie as it is in Zdoom). However, as you point out, it doesn't seem to be done that way on testing it with Doom.exe.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49098
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Post by Graf Zahl »

Enjay wrote: So, rather oddly, the texture is set up differently in Doom1 and Doom2. Because of the offsets, I would expect the bottom 4 pixels of that odd bit of the W105_1 patch to be visible in Doom1 when the texture was used on a door (ie as it is in Zdoom). However, as you point out, it doesn't seem to be done that way on testing it with Doom.exe.

AFAIK Doom is not capable of handling patches larger than 128. It probably was just random luck that it looked correctly in Doom 1.
User avatar
HotWax
Posts: 10002
Joined: Fri Jul 18, 2003 6:18 pm
Location: Idaho Falls, ID

Post by HotWax »

IMO, given that the original behavior was actually a glitch of Doom's renderer, and that this isn't a game-killing compatibility issue, I'd leave things as they are now. Otherwise you either have to code a special case just for this texture, or else risk messing up textures designed for ZDoom.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49098
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Post by Graf Zahl »

I agree. This was changed for a reason in Doom 2 and if it bothers anybody it stops no one from fixing it oneself in the WAD.
User avatar
Xaser
 
 
Posts: 10772
Joined: Sun Jul 20, 2003 12:15 pm
Contact:

Post by Xaser »

Why not include a texture2 lump in zdoom.wad that fixes the door?
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49098
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Post by Graf Zahl »

ZDoom.wad is loaded before the IWAD so the fix wouldn't have any effect.
NiGHTMARE
Posts: 3463
Joined: Sat Jul 19, 2003 8:39 am

Post by NiGHTMARE »

Yeah I've noticed this too. I think this door shows up like this in a few other ports besides ZDoom as well.

BTW this isn't the only texture that looks different in Doom 1 & 2; SHAWN1 does as well. IIRC in Doom 1 it has stone on the right side, whereas in Doom 2 it's all silver.

On second thoughts this might be something that was fixed in a late Doom 1 patch; I'm not too sure and I can't really check right now as Doom 1 isn't on this computer.
User avatar
randi
Site Admin
Posts: 7746
Joined: Wed Jul 09, 2003 10:30 pm
Contact:

Post by randi »

Added a hack to make this texture show up properly. The "problem" is that I added support for negative patch y offsets, and this is one texture that actually has a negative y offset. (Doom's SKY1 is another.)
Post Reply

Return to “Closed Bugs [GZDoom]”