<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - Torchlight: crash due to texture error" href="https://bugs.freedesktop.org/show_bug.cgi?id=55445#c6">Comment # 6</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - Torchlight: crash due to texture error" href="https://bugs.freedesktop.org/show_bug.cgi?id=55445">bug 55445</a> from <a class="email" href="mailto:screwtape@froup.com" title="Tim Allen <screwtape@froup.com>"> Tim Allen</a> <pre>In the thread linked from <a href="show_bug.cgi?id=55445#c2">comment 2</a>, the guy who ported Torchlight to Linux says that the actual call to glCompressedTexture2D() happens within the bowels of the OGRE 3D library and so the exact parameters aren't readily available without some kind of debugging/API-tracing tool. I'll see what I can do, if nobody else beats me to it, but in the interim here's what we do know: - Using Mesa-based GL drivers (that is, not the proprietary nVidia/ATI drivers), Torchlight always crashes when descending from dungeon-level 19 to dungeon level 20. - When it crashes, Ogre prints the message pasted in <a href="show_bug.cgi?id=55445#c0">comment 0</a>, naming mipmap 2 of "trail37.dds". - It turns out, trail37.dds is one of three textures (out of 2776 in the game) that have non-power-of-two dimensions. Specifically, it's 200x64 pixels. - trail37.dds is also S3TC-compressed (like all but 16 of the game's textures), which means its dimensions need to be a multiple of 4 in each direction. - The base texture is 200x64 pixels, which is fine. - Mipmap level 1 is 100x32 pixels, which is fine. - Mipmap level 2 is 50x16 pixels, but 50 is not a multiple of 4. mesa/main/teximage.c has specific code to return GL_INVALID_OPERATION if given dimensions that aren't a multiple of the compression algorithm's block-size, and the error message it includes is exactly the one seen if you start Torchlight with MESA_DEBUG=1 set. This is also consistent with the Ogre error that mentions mipmap 2. It's not immediately clear what Mesa *should* do when fed compressed texture data that isn't a multiple of the block-size, apart from 'not crash'. It looks like <a href="attachment.cgi?id=67879" name="attach_67879" title="I'm still so sorry for this thing.">attachment 67879</a> <a href="attachment.cgi?id=67879&action=edit" title="I'm still so sorry for this thing.">[details]</a> <a href='page.cgi?id=splinter.html&bug=55445&attachment=67879'>[review]</a> opts for "quietly round the dimensions up to the nearest multiple of four", but that doesn't seem right - you'd wind up with 1-3 pixels of black (or gibberish, depending on how the compression works), at the edge of the texture. I notice Mesa already has some support for such textures: the error-detecting code in teximage.c actually tests "(width > bw && width % bw > 0)" so presumably a 1x3 or 2x4 texture would work just fine. Whatever Mesa does to clip off unwanted pixels when "width < bw", I guess it should do in the "width > bw" case as well.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>