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.
I'm so confused, don't we already have the sampler_dim field in objects_usage? Why do we need another one, or two different is-combined-sampler boolean fields?
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):
Well, besides this I guess...