<html>
    <head>
      <base href="https://bugs.freedesktop.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW --- - Torchlight: Texture renders as garbage"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=55817#c6">Comment # 6</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW --- - Torchlight: Texture renders as garbage"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=55817">bug 55817</a>
              from <span class="vcard"><a class="email" href="mailto:screwtape@froup.com" title="Tim Allen <screwtape@froup.com>"> <span class="fn">Tim Allen</span></a>
</span></b>
        <pre>If you look at the screenshots, you'll see the wall is constructed with a
crumbly bit at the top, followed by a dark band with a curly motif, a stretch
of plain bricks, and another curly-motif band at the bottom. In the screenshot
of Mesa 8.0.4, you'll see that in the wall-segments that have the problem,
everything from the upper band to the ground is missing. So, whatever problem
Mesa is having, causes that entire texture to not work - the entire brick
section, plus the bottom band.

However, if you look at the actual problematic texture (the 511x256 one) in the
game's data files, it doesn't contain an entire brick section or a bottom band,
it just has a few bricks in the middle with holes for emitting poison darts. In
fact, if you look at <span class=""><a href="attachment.cgi?id=68354" name="attach_68354" title="Screenshot of bug with Mesa git">attachment 68354</a> <a href="attachment.cgi?id=68354&action=edit" title="Screenshot of bug with Mesa git">[details]</a></span>, the problematic texture covers *exactly*
the area that's rendered as garbage.

Although it's not depicted in these screenshots, apparently if you can trick
the game into moving the camera close to the wall so you can see the base
texture instead of a mipmap, that renders just fine.

So, the game doesn't render this 511x256 texture directly, but apparently at
some point it combines it with some other texture with a sensible size (all the
other wall textures are 512x512) producing a texture whose mipmaps are a
glitchy mess even though the base texture is OK. 

However, the obvious way to combine textures would be with
glCompressedTexSubImage2D, and the apitraces linked in <a href="show_bug.cgi?id=55817#c0">comment 0</a> contain no
such calls. There's some calls to glTexSubImage2D, but very few, and all of
them have x and y set to 0 - and our dart wall is being drawn in the middle of
the original wall texture.

For the record, all these things are apparently sufficient (although none of
them are necessary) to make the wall render as intended:

- resave the original texture without compression.
- resave the original texture after rescaling to 512px wide.
- resave the original texture without the precalculated mipmaps.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>