What's ZDoom's problem with DOOR1?

[Jodwin]

prboom+:


ZDoom:


What!?

[Andrea Rovenski]

Not sure, I use my custom variants so I wouldn't know. I made them just because of this, too.

[printz]

ZDoom still has vertical texture tiling tutti-frutti (except without the extra garbage vanilla has). Textures not powers of 2 cannot be tiled correctly in software ZDoom.

Manhunt21 said:

Not sure, I use my custom variants so I wouldn't know. I made them just because of this, too.

I don't like that because of this, you're forced to go the overused 128-tall room scheme.

[Gez]

That's not tutti-frutti. Tutti-frutti is "the extra garbage vanilla has".

[Jodwin]

printz said:

ZDoom still has vertical texture tiling tutti-frutti (except without the extra garbage vanilla has). Textures not powers of 2 cannot be tiled correctly in software ZDoom.

It doesn't tile properly in OpenGL GZDoom for me either.

[Graf Zahl]

I have no idea what you did wrong but DOOR1 sure displays properly in both DOOM.WAD and DOOM2.WAD maps.

Have you loaded any texture WAD that might redefine it?

[Jodwin]

Graf Zahl said:

I have no idea what you did wrong but DOOR1 sure displays properly in both DOOM.WAD and DOOM2.WAD maps.

In the mock-up screens the door sector is 76 units tall and the texture is vertically aligned by a few units.

[Graf Zahl]

Ok.

The effect in ZDoom is to be expected.
GZDoom should handle it properly though. What graphics card do you have?

[Jodwin]

Hmm, ignore that about GZDoom - it was showing it was on OpenGL mode in display options but apparently it was on software mode instead. :S Setting it to software and then back to OpenGL fixed that one.

Anyway, why does ZDoom still have this bug? Apparently it should be fixable considering that it's fixed in prboom+.


EDIT: My GZDoom isn't exactly up to date, but in this version if you use "Disable OpenGL" in the OpenGL settings it doesn't set the renderer option in "Set video mode" to software but keeps the selection in OpenGL. Don't know if that's been fixed already, though.

[Graf Zahl]

Efficiency reasons, I presume (nonsense if you ask me though ;) .) The low level rendering code is highly optimized assembler and adding divisions might cause problems. With powers of two you can just use a relatively cheap 'and' instruction instead of a more costly 'div'.

If I could make sense of the software renderer I'd have fixed it long ago but that code just gives me the creeps.

If you want you can try to report it. But unless the texture wrapping was fixed in Boom so you can report is as a Boom compatibility issue I doubt you'll have success.

[40oz]

hooray jodwin is testing his boom compatible wads in zdoom!

[Jodwin]

40oz said:

hooray jodwin is testing his boom compatible wads in zdoom!

Haha, actually I'm not, one of my testers is. ;) Why bother when you can delegate?