Texture and Texture Manager. Best Approach?
Author
Hi,
I have a texture class, and a texture manager class (basically a hash table with a counter to the number of objects using the texture).
Should ALL textures be created through the texture manager, or should the engine allow texture objects to be created outside the control of the manager? At the moment I am keeping a pointer to the texture manager in the texture so when the texture is released, it call call the manager to decrement the count and delete if necessary. Is this the best approach?
What have others done in their implementations?
I guess it depends on how you want to do things, but Im a big fan of consitency in your engine.
With that in mind I would not allow for any Texture creation outside of the manager, because it seems to go against the purpose. Also I would use an explicit deletion method for your textures that goes thru your Manager because youre using an explicit creation method.
With that in mind I would not allow for any Texture creation outside of the manager, because it seems to go against the purpose. Also I would use an explicit deletion method for your textures that goes thru your Manager because youre using an explicit creation method.
I would keep it all going through the manager, otherwise you'll have a tough time cleaning everything up afterwards. But then again, it all depends on your implementation.
I guess the question is, why would you want to by-pass the manager?
I guess the question is, why would you want to by-pass the manager?
Perhaps make all texture objects have a pointer to the texture coordinator, so that no matter what happens, or how it's manipulated, it's recorded in the texture manager...
I'd go for a singleton texture management class (you dont want more than 1 instance per application I wouldn't have thought?), you could also go for a smart pointer system, where by when the textures are no longer used they are destoryed from memory (as images are expensive in terms of memory). Like Larz says you definately want whatever you choose to be consistant with the rest of your engine.
My texture manager is more a skin manager. Skins define the appaerance of objects including Material info and multiple textures. It stores Image Objects with all the important image data and calls the renderer to convert these into textures. This way it is not bound on any graphics api since it only stores id's to those texture objects.
The indexes to the skin objects are the exact locations in a stl vector.
The renderer gets the skin object to be assigned to the geometry and sets everything accordingly(N/POT, filtering, etc. )
so long
The indexes to the skin objects are the exact locations in a stl vector.
The renderer gets the skin object to be assigned to the geometry and sets everything accordingly(N/POT, filtering, etc. )
so long
Raeldor,
If this is C++ you might use boost::shared_ptr or some other similar smart pointer as your texture handle. Then textures don't need a pointer to the manager they belong nor you don't need code to update their use count.
// ville
If this is C++ you might use boost::shared_ptr or some other similar smart pointer as your texture handle. Then textures don't need a pointer to the manager they belong nor you don't need code to update their use count.
// ville
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
