Skip to main content
GameDev.net gamedev.net
🔒 Locked

Boost.Flyweight for Resource Management?

Started by GenuineXP Nov 23, 2009 at 3:11 PM 3 replies 2.4k views
Original Post
GenuineXP
GenuineXP
So I've taken a look at the Boost.Flyweight library and it seems quite nifty. I'm curious if it would be good for resource management though. For example, would a setup like the following be reasonable? (I did not try to compile this code; there are probably mistakes.)
class resource {
public:
	typedef boost::uint_fast32_t id_type;
	virtual ~resource();
	id_type get_id() const;
private:
	id_type id_;
};
struct resource_id_extractor {
	resource::id_type operator()(const resource &r) const {
		return r.get_id();
	}
};
std::size_t hash_value(const resource &r) {
	boost::hash<typename resource::id_type> hasher;
	return hasher(r.get_id());
}
bool operator==(const resource &lhs, const resource &rhs) {
	return lhs.get_id() == rhs.get_id();
}
typedef boost::flyweight<boost::key_value<typename resource::id_type, resource, resource_id_extractor> > resource_handle;

class texture : public resource {
};

This would index resources by a unique ID. Coupled with a package system that assigns a unique ID to resources stored on disk, it looks like Boost.Flyweight would provide all the plumping for quick and easy lookup and management of those resources. What do you think? I'm interested in what people think about the library in general as well. Thanks.
Telastyn
Telastyn
Maybe? I've not looked at the library, but most of the problems with resource management isn't making sure there's one of a resource; that's easy. It's the intelligent caching and being able to sufficiently abstract 'how do I load X if it's not there?' variability...
GenuineXP
GenuineXP
Quote:
Original post by Telastyn
It's the intelligent caching and being able to sufficiently abstract 'how do I load X if it's not there?' variability...

Good point. Since they're using a hash table under the hood (at least I assume so), I would hope that caching would also be handled reasonably well by using boost::flyweight objects.

Since I would identify resources (statically) with a unique ID, the whole, "How do I load x if it's not there?" part is a matter of the flyweight seeing that the expected ID isn't already in use and constructing a new object (which in turn actually loads the content). I would most likely use strings for IDs and not integers as I did in the above code. As long as resources are always referred to by ID, the flyweights could keep things tidy.

...texture_handle tex0("some-awesome-texture"); // Key not already in use, so construct a texture object, loading the data with that ID.texture_handle tex1("another-amazing-texture"); // Key not already in use; same deal....texture_handle tex2("some-awesome-texture"); // Key has been used, so just reference the existing object....

I figured I would experiment with this in a sort of "package" system I'd like to use. It at least seems to solve part of the problem of resource management.

One thing I haven't thought of until now was releasing resources allocated this way. I'm not sure boost::flyweight provides a mechanism for that.

Any chance anyone has actually used or attempted this before?
Telastyn
Telastyn
Quote:

Since they're using a hash table under the hood (at least I assume so), I would hope that caching would also be handled reasonably well by using boost::flyweight objects.

Since I would identify resources (statically) with a unique ID, the whole, "How do I load x if it's not there?" part is a matter of the flyweight seeing that the expected ID isn't already in use and constructing a new object (which in turn actually loads the content).


You perhaps misunderstood my point, or more likely misunderstand the problem. Intelligent caching in games frequently needs to purge the cache at times to not fill up memory. Changing on a level perhaps, or dropping the least used, or oldest entry in the cache. You'll need to do that outside of the flyweight, which is decidedly more difficult than returning just one.

And loading the resource itself isn't commonly done by the object itself. Especially with resources simply known by ID (or name), there might be a half dozen loading mechanisms depending on what the object is (load from server, construct dynamically, load from file, load from some zip construct, check if the user has purchased that content, etc).

To be honest, the flyweight part of resource management is as easy as making a hash_map and a few wrapper functions. Not exactly rocket science beyond picking a hash_map implementation...
GenuineXP
GenuineXP
Yes, I see now that intelligently handling the loading and unloading of resources is a problem not solved by Boost.Flyweight. It doesn't look like it's very suitable for resource management in a game, and as you stated, building a hash table by hand isn't difficult anyway. That's about all it provides here.

Thanks for the input. :-) It's a cool library, and I wanted to explore the applications.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.