Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
Jodwin

What's ZDoom's problem with DOOR1?

Recommended Posts

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.

Share this post


Link to post

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

Share this post


Link to post
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.

Share this post


Link to post

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?

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post
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?

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
×