While the current SDL_GpuTextureCreateInfo struct design gets the job done, I think it could be improved for usability and clarity. What we have currently is this:
This is a collection of texture properties that covers all possible scenarios (depth, 2D, arrays, etc.), but it's not clear which properties are compatible with one another, or what the "default" values should be. It raises questions like:
If you're creating a 2D texture, what should the depth value be? 0? 1?
If you're creating a cube texture, what should the layer count be? 0? 1? 6? Are cube layers the same as texture array layers? Can you have a texture cube array?
If you create a cube texture with a sample count > 1 is that valid? What about a depth value of > 1, or mismatched width/height?
If you create a 3D texture with a sample count > 1 is that valid? What about a layer count > 1? Are 3D depth slices the same as layers?
If you create a multisample 2D texture with a level count > 1 is that valid?
Having this many individual, incompatible settings all presented in one grab-bag is clearly less than ideal. A potentially better option would be to follow the D3D11_VIEW_DESC approach, where we have a tagged union of texture types that only contain the options actually applicable for that type. Something like:
This isn't 100% perfect since you can still have incompatible type/format/usage pairings, but I think it substantially lightens the mental load of having to remember all the rules about which properties work with which types.
While the current SDL_GpuTextureCreateInfo struct design gets the job done, I think it could be improved for usability and clarity. What we have currently is this:
This is a collection of texture properties that covers all possible scenarios (depth, 2D, arrays, etc.), but it's not clear which properties are compatible with one another, or what the "default" values should be. It raises questions like:
Having this many individual, incompatible settings all presented in one grab-bag is clearly less than ideal. A potentially better option would be to follow the D3D11_VIEW_DESC approach, where we have a tagged union of texture types that only contain the options actually applicable for that type. Something like:
This isn't 100% perfect since you can still have incompatible type/format/usage pairings, but I think it substantially lightens the mental load of having to remember all the rules about which properties work with which types.