Matteo Bruni (@Mystral) commented about dlls/d3dx9_36/d3dx9_private.h:
- void (__stdcall *d3dx_resource_release)(struct d3dx_resource *resource);
+};
+#define d3dx_resource_release(resource) (resource)->resource_ops->d3dx_resource_release(resource) +struct d3dx_resource +{
- const struct d3dx_resource_ops *resource_ops;
- enum d3dx_resource_type d3dx_resource_type;
- D3DRESOURCETYPE resource_type;
- D3DFORMAT format;
- uint32_t width;
- uint32_t height;
- uint32_t depth;
- uint32_t mip_levels;
+};
Is `d3dx_resource_type` useful? If I'm reading this correctly, it's only ever used for the `assert()` in `d3dx_image_resource_from_resource`, which doesn't seem critical, especially considering how these d3dx_resource objects are going to be used (i.e. it seems unlikely that there's going to be a real chance to mix up d3dx_resource pointers with something else).
Then, as a first (probably won't be the last...) naming consideration: It seems more natural to call this e.g. `d3dx_texture`. What do you think? I realize that making the change would require touching a ton of places over many patches, so feel free to ignore this kind of comments, unless you end up having to rewrite stuff anyway. Which brings me to...
Would it be possible to implement all this in a reasonable fashion without callbacks? I haven't thought this all the way through so the answer might just be "no". That said, the idea would be to rework the code flow and move all the "context specific" calls out of generic code into the version / API-specific d3dx* side, which knows e.g. what particular `release()` function to call, thus avoiding extra indirection.
To me, it looks like this should be fine for the `release()` callback at least. The only 2 calls to `d3dx_resource_release()` in the d3dx_helpers.c from your branch are in error paths and can be presumably hoisted to the callers and replaced with direct calls. That's not immediately clear for the two other callbacks (`d3dx_resource_get_sub_resource` and `d3dx_resource_release_sub_resource`, introduced later). I think I'd still prefer to duplicate the per-layer, per-level loops, or to allocate extra temporary storage, if it means getting rid of callbacks. I can be convinced otherwise though.