Wait, why can't these be in object_usage[]?
They could be, but that would still be additional fields that could simply be stored in the new variable with the infrastructure we currently have.
Also, in native these values (however they are stored) are unique for the whole variable. For that reason the test I added doesn't compile in tpf profiles with compatibility mode (while it is perfectly valid in d3dbc profiles):
``` sampler sam[2];
float4 main() : sv_target { return tex2D(sam[0], float2(0, 0)) + tex3D(sam[1], float3(0, 0, 0)); } ```
Adding it in object_usage[] also adds the inconvenience of having to iterate over all the components to check if the sampler_dim usage is consistent for all combined sampler **components**. And also, we would have to remember to check object_usage[HLSL_REGSET_SAMPERS] even though the deref is in HLSL_REGSET_TEXTURES.
That doesn't seem particularly visible in 28af38f7106c?
All these things are not necessary if we just create a separate variable:
* The conditional in hlsl_offset_from_deref() (https://gitlab.winehq.org/fcasas/vkd3d/-/commit/28af38f7106c30e3f632310ebe54...)
* The need to create an additional extern resource in sm4_get_extern_resources() both when separated components (https://gitlab.winehq.org/fcasas/vkd3d/-/commit/28af38f7106c30e3f632310ebe54...) and (https://gitlab.winehq.org/fcasas/vkd3d/-/commit/28af38f7106c30e3f632310ebe54...)
* The check when writing the CTAB entry (https://gitlab.winehq.org/fcasas/vkd3d/-/commit/28af38f7106c30e3f632310ebe54...)
* Conditionally changing the regset so that objects_usage information is obtained from the correct objects_usage[regset] (yes, this wouldn't be necessary if objects usage is component-wise, but it is just a detail) (https://gitlab.winehq.org/fcasas/vkd3d/-/commit/28af38f7106c30e3f632310ebe54...).
* Having to create sm4_resource_dimension_from_sampler_dim() since sm4_resource_dimension() cannot be used directly now because we don't have a texture type we can pass as an argument (https://gitlab.winehq.org/fcasas/vkd3d/-/commit/28af38f7106c30e3f632310ebe54...)
* Having to bypass sm4_resource_format for the same reason (https://gitlab.winehq.org/fcasas/vkd3d/-/commit/28af38f7106c30e3f632310ebe54...)
And the problem is not only these things, but also having to keep in mind that this exception exists.
Also come to my mind some inconveniences like having to create a separated allocation function just so that the sampler resources get allocated first ( https://gitlab.winehq.org/fcasas/vkd3d/-/commit/607f22ba836c73ab9ab16ccefdb2...) where in the alternative it is just a matter of sorting the new variables first.