Andrea Rovenski Posted September 2, 2010 Not sure, I use my custom variants so I wouldn't know. I made them just because of this, too. 0 Share this post Link to post
printz Posted September 2, 2010 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. 0 Share this post Link to post
Gez Posted September 2, 2010 That's not tutti-frutti. Tutti-frutti is "the extra garbage vanilla has". 0 Share this post Link to post
Jodwin Posted September 2, 2010 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. 0 Share this post Link to post
Graf Zahl Posted September 2, 2010 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? 0 Share this post Link to post
Jodwin Posted September 2, 2010 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. 0 Share this post Link to post
Graf Zahl Posted September 2, 2010 Ok. The effect in ZDoom is to be expected. GZDoom should handle it properly though. What graphics card do you have? 0 Share this post Link to post
Jodwin Posted September 2, 2010 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. 0 Share this post Link to post
Graf Zahl Posted September 2, 2010 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. 0 Share this post Link to post
40oz Posted September 2, 2010 hooray jodwin is testing his boom compatible wads in zdoom! 0 Share this post Link to post
Jodwin Posted September 2, 2010 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? 0 Share this post Link to post