[Mesa-dev] [Bug 55445] Torchlight: crash due to texture error

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=55445

--- Comment #6 from Tim Allen <screwtape at froup.com> ---
In the thread linked from comment 2, 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 comment 0, 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 attachment 67879 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20121002/e6f7b44b/attachment-0001.html>