Quote:Original post by rick_appleton
I don't agree with your choice of adding a cleanup function, especially as it can be done automagically by unregistering the handle in the destructor, and cleaning up when the last reference is gone (requires ref-counting), but it's your choice :D
I thought I would expand on why I went the way I did [smile]
The idea of having the clean up happen automagically did occur to me, however there is the matter of the amount of work this would require.
In the classic system, where everything is a shared_ptr (as of v0.1), if you ask the manager to deregister everything then each run you have to check to see if the manager is the only thing which holds a handle to the resource and release if so. Also, unless you have a second structure which maps TextureHandles to strings you are going to have to search the whole map each time, which in a game with alot of textures could be bad mojo indeed.
Given that textures, in a classic level based game, are generally only loaded and unloaded at map changes this is also a hell of a waste of time; for each object you'd have to do the check on unload if the manager was the last thing to hold a refernce to it, this would involve transversing the whole map to look for the object.
In a "streaming" based game the same concerns apply, however depending the size of your texture set again the runtime costs of transversing the map for every object delete could well be unacceptable. Having a way of controlling the release time allows you to control when it happens.
Finally, we come back to the burnden on client code;
Each class which interacts with the texture manager is required at destruction to tell the texture manager it has done with its texture(s). Now, unless you are going to sub-class ALL your in game objects from the same base class which deals with the destruction 'somehow' you have to constantly write the code to release the textures, be it in a destructor or another function.
Chances are you'll miss one or two, which could leave you with potentially large resources laying around which you don't need any more (at 2,048*2,048 RGBA texture for example takes up 16Meg of ram before mipmaps...).
When it comes to the new design the problems above mostly vanish, the only burden on client code is that the clean up function is called, which allows you to control when it happens.
Of course, while writing this the idea of having the texture handle its self tell the manager it is dying occured to me (and might well have been what Rick was driving at in the first place..), however this still leaves the reverse lookup problem plus right now I'm not sure how a weak_ptr => shared_ptr lock behaves when the objects are being cleared up.
Also, I've got plans for the future when it comes to the policy system which might well make it more flexible than it appears as it stands [smile]
Oh, and finally, the code below is missing a call to glDeleteTexture() in the TextureHandle destructor.
Thats all for now...
