[source lang = "C++"]
class JTexture : public IDirect3DTexture9
{
public:
ULONG __stdcall Release(void)
{
ULONG ref_cnt = IDirect3DTexture9::Release();
if(!ref_cnt)
{
// remove the instance from the resource manager
JTextureManager::Unacquire(this);
}
return ref_cnt;
}
};
Questions about resource management in game engine design.
Author
Hello,
I have questions about resource management in game engine design.
Ok, so I have a templatized resource manager that I use as a base class for my other resource managers ... i.e. textures/physics scripts/generalized objects/effects etc. This all works fine, and the design is solid except that I have one situation that I cannot find an optimal way to handle. The resources are instanced and managed using the fundamentals of COM (AddRef, Release) to provide accurate instancing.
Currently the resource managers provide only private methods accessible only by friend functions that are part of the API for my engine. Examples are JCreateTexture/JCreateEffect etc. The resources that are returned from these functions are COM resource pointers (they use AddRef/Release for instancing purposes within the resource managers). The Release method of the returned resource instance decrements the ref count and if it is zero it deletes the object from the resource manager ( again it is a friend function).
The problematic situation is when managing resources that are already COM objects such as DirectX textures and effects. The reason for the problem is that there are really now two COM objects associated with the resource, one that is a DirectX COM object and one that is a COM object in terms only of my API. This gets tricky because you want to call the proper Release version since there are two versions now around.
If I store the DirectX resource as a member, than one has to access it via an accessor function (not too clean), and worse yet if one Releases via the accessor version and not the version of my API then things can possibly get screwed up. Ideally one should not ever be able to access the DirectX Release method since my API is the proper version to use at all times (it calls the DirectX version but cleans the other stuff up as well). So ... I tried derivation.
One example scenario I tried was:
This overrides the Release method properly, but I cannot for the love of god figure out a way to correctly instantiate the JTexture now that the problem is fixed. You cannot instantiate it because the IDirect3DTexture9 methods are all pure virtual. I do not think you can pass a pointer to a JTexture in place of a IDirect3DTexture9 in a call to D3DXCreateTextureFromFile because only an IDirect3DTexture9 will be allocated and assigned.
If anyone has an idea about how to solve this dilmena or has any input I would greatly appreciate it.
Thank you,
Jeremy
I wouldn't derrive from IDirect3DDevice as you are there, most code i have seen creates a thing wrapper around it, or hides it behind a much more abstract interface.
Do not inherit from IDirect3D*. You can't do that unless you're willing to implement yourself all the methods of those interfaces. This is possible (I've done it) but definitely not a good idea for resource management purposes.
You'll want to wrap your platform's native texture objects (here: IDirect3DTexture9) into a class of your own that additionally stores engine-specifics things (most likely, an ID at least, perhaps the texture dimensions and format, the name, and so on)
I wouldn't worry so much about someone releasing the internally wrapped texture object, by-passing the wrapper object. Only the internal part of your engine should be accessing the native texture. Don't try to prevent someone from intentionally screwing things up. And finally, why do you think you need an accessor to the native texture? Your texture wrapper should be able to provide a high-level interface to all of your texture's functionality without ever exposing the underlying object to the users.
You'll want to wrap your platform's native texture objects (here: IDirect3DTexture9) into a class of your own that additionally stores engine-specifics things (most likely, an ID at least, perhaps the texture dimensions and format, the name, and so on)
I wouldn't worry so much about someone releasing the internally wrapped texture object, by-passing the wrapper object. Only the internal part of your engine should be accessing the native texture. Don't try to prevent someone from intentionally screwing things up. And finally, why do you think you need an accessor to the native texture? Your texture wrapper should be able to provide a high-level interface to all of your texture's functionality without ever exposing the underlying object to the users.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
