Re: [PATCH 2/5] wined3d: Introduce resource-type specific format flags.
On 23 April 2015 at 11:28, Stefan Dösinger <stefan(a)codeweavers.com> wrote:
+ /* Always check 2D textures here, we don't want to write this ERR when the app tried + * to create a compressed volume texture but s3tc support is otherwise available. */ if ((desc->format == WINED3DFMT_DXT1 || desc->format == WINED3DFMT_DXT2 || desc->format == WINED3DFMT_DXT3 || desc->format == WINED3DFMT_DXT4 || desc->format == WINED3DFMT_DXT5) - && !(format->flags & WINED3DFMT_FLAG_TEXTURE) && !once++) + && !(format->flags[WINED3D_GL_RES_TYPE_TEX_2D] & WINED3DFMT_FLAG_TEXTURE) && !once++) ERR_(winediag)("The application tried to create a DXTn texture, but the driver does not support them.\n"); But now it's still going to write an ERR when it tries to create a volume texture and s3tc support is unavailable. Wouldn't it make more sense to just explicitly exclude volume textures by adding a "desc->resource_type != WINED3D_RTYPE_VOLUME_TEXTURE" condition?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-04-23 um 13:52 schrieb Henri Verbeet:
But now it's still going to write an ERR when it tries to create a volume texture and s3tc support is unavailable. Wouldn't it make more sense to just explicitly exclude volume textures by adding a "desc->resource_type != WINED3D_RTYPE_VOLUME_TEXTURE" condition? This was intentional (hence the "otherwise" in the comment), because I think having an application that in any way tries to use DXTn and having no DXTn support is worth warning the user about. I don't have any objections against never writing this for volumes though. I seriously doubt that there's an application that doesn't need DXTn 2D textures but tries to create a DXTn volume texture.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVOOS1AAoJEN0/YqbEcdMwDawQAJMDnPgtmpktD5gHiTrmgqkT Ssz1BIpl2F08jqy2XZk38ASw/EH4VG/vfsyFtGZRtM8nPe2FdQTjOfxtnEcl6kp4 lEt6oYb7DAwCbuvLkvkowGNKNs/QfDlxJOmO+a+61AA+aN/WVLyFyp940p2sw/g/ Wo8VnUqC9xKKnP5pAEohvUjrPxdV3hfSO9faf9vk7Ph0MY711nXEJfY+JEY5/FCG 4YhO+Ckg6Ln75zVklL5IpwoOK+H/8B0VUiMmBmrXWvZjrNZkIxxUS3kTfkLN3VUA 1CAM2DclLvxKG+mfF6Woca1QUiH/Ef82i/jxJqFXDoppXnoe9exUWl9D0nE3VvjL 4w1ZYqfhBXEHRmTbHtVjXHq4nC9WGuU1rBlB/uu44cp+tMRZzF38i6kMAKTpJEIN 2Sdej41mjw1zZp9H6SNLeunQMYK9GFMS7BKLSEhS1PhR04plTx5TIx1FAGQudIIb UxBuz8fPIEuj+Nuk0KoMIPkUvrYRTMEaJlNw97OggBJi5ltsO6NVNPaBrYeCnqrI Z7wqk39rcBJ3F9gGL2iyjqJonMnKmhDa5RKI+e7Qfx8bXEfv07uTuGaCrhMhooZv 98/KJgdI74DAracxcRuK4YzHZCnn3oTDqUPodeDED/pJLWpv8epjv9e0IeulJopG mpJTS1/P1na3Xeq+MSlc =DBKL -----END PGP SIGNATURE-----
On 23 April 2015 at 14:25, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote:
Am 2015-04-23 um 13:52 schrieb Henri Verbeet:
But now it's still going to write an ERR when it tries to create a volume texture and s3tc support is unavailable. Wouldn't it make more sense to just explicitly exclude volume textures by adding a "desc->resource_type != WINED3D_RTYPE_VOLUME_TEXTURE" condition? This was intentional (hence the "otherwise" in the comment), because I think having an application that in any way tries to use DXTn and having no DXTn support is worth warning the user about. I don't have any objections against never writing this for volumes though. I seriously doubt that there's an application that doesn't need DXTn 2D textures but tries to create a DXTn volume texture.
But that's the thing, this will only make a difference for applications that try to create DXTn volume textures, but never try to create DXTn 2D or cube textures. But creating a DXTn volume texture is going to fail either way, regardless of whether the driver has s3tc support or not. So you create a situation where you're suggesting to users that they should somehow acquire s3tc support, but already know in advance that it isn't going to make a difference.
participants (2)
-
Henri Verbeet -
Stefan Dösinger