Texture alligment errors!

[Optimus]

I used to map in Doombuilder and tested my maps with Zdoom.
Later, I decided to run a map in other doom ports to see that few textures are alligned quite strangely there or show up a rendering bug (especially the old doom engine or chocolate-doom, but even legacy bugs me the same way). I think I have seen the first bug in few Doom WADs and it has to do with specific textures, tell me about it, but what can you tell me especially for the second? That one seems preety strange..


Strange colors there. I think I shouldn't use this texture for walls heigher than it's height?


But I find this even more weird. I use that texture, aligned at Y=0 and then the first piece to the left has X=0 and I allign the whole big box line serially on X by pressing the A key upon that mostleft piece in Doombuilder 3d view. (There are several line segments making up the box wall, cause I've splitted sectors near there so that I can do the lightning partialy). Why does the allignment of the big box show up screwed up in vanilla doom when it's ok in Zdoom or Doombuilder 3d view?

[kristus]

Because it's a bug that has been fixed in Boom, which Zdoom is based on. I seem to recall that Legacy have this fixed also in the latest version though.

Any texture that is less than 128 units tall will give this bug when tiled vertically.

[Donce]

Yeah, and it's called a Tutti-Frutti effect.

[Grazza]

The other issue you mention is probably explained by Graf Zahl's post here.

[Ezxariarch]

Sometimes using an Newer version of Doombuilder to edit maps made with older Doombuilders to cause this weird "Ok in Zdoom but not in anything else" bug. I have no idea why.

[Use]

Grazza said:

The other issue you mention is probably explained by Graf Zahl's post here.

A very annoying behaviour in zdoom imo.

[Grazza]

I agree completely; Zdoom's "forgiving" of certain types of tag errors has a similar type of impact too. If a map is intended for either any Boom-compatible or any limit-removing port, but has only been tested with Zdoom, certain types of errors may never be picked up as a result.

[Graf Zahl]

Use3D said:

A very annoying behaviour in zdoom imo.

I'd call it a bug in the other ports. I am wondering why they stillhave to use a precalculated value inside the segs to place textures when the problem is known and it is much more robust to calculate the texture offset itself

The first time I encountered this problem was when I experimented with PrBoom's GL renderer and using WARM as a node builder. After seeing what happened the first thing I did was to change the offset calculation so that this node builder issue is circumcented. Apparently nobody else is bothering with this fix (which, btw, would probably take less than a minute to implement.)

Of course, if someone is to create a 'Boom compatible' map and then just testing on ZDoom it's rather pathetic to blame a source port for one's own laziness. You always have to test on the lowest specs you are developing for.

[DaniJ]

What is the actual bug here?

[Optimus]

Thanks.

I guess I'll just have to use another texture of height 128 or just make additional gfx of the tiny box tiled in a single 128-height texture to fix the first problem.

As for the second bug, preety interesting thread you have there, I'll try some other nodebuilders and see if it's fixed. Or I'll just move around few lines or delete unneeded vertices/lines. I am wondering, is this bug usually happening in complex maps where there are a lot of sectors or detail in a tiny space? I should not put so many vertices for curved sectors if so ;P (I was hooked by curve line function in doom editors and overused it :)

p.s. It always annoyed me when doom was so limited in some areas, especially at the older times when I tried to do complex maps with Deu. I wasn't even using a proper Node builder back then. Now I started doing stuff and testing them in Zdoom, sometimes I think I am getting spoiled by drawing unneeded complex stuff in few areas just because I can, so I am looking back lately by running my maps under Chocolate-Doom in order to be a little more compatible to the old limitations too (But I am not going to fix these visplane errors in this map! :)

[Graf Zahl]

DaniJ said:

What is the actual bug here?

Doom gets the texture offset for segs from a field in the seg structure that is precalculated by the node builder. ZDBSP occasionally writes incorrect values in that field.

I have no idea why it was done that way in the first place because it actually is quite redundant data that can be easily retrieved during loading the level.

[DaniJ]

Ah ok. I'm working on the map loading code in Doomsday atm (a complete rewrite and moving it engine-side) so I'll see about calculating the offsets automatically.

[Grazza]

Would it not make sense to fix the bug in zdbsp that is causing the problem in the first place? (Given that quite a lot of people use it for maps that are designed to be played in other exes too.)