Elysian Shadows

Hi,

I got pissed at my previous asset manager last night and got rid of the whole damn thing. So I wrote a small, extensible asset management template library using C++11 to replace it. It's very RAII friendly and I thought some of the folks on here might find it useful. It's on GitHub at http://github.com/nokurn/nam. There's a tutorial for basic usage on the wiki, as well as a link to the Doxygen generated documentation.

Bug reports and feature requests are welcome. I'll be watching this topic, so feel free to ask questions. It's dead simple to use, so I doubt anyone will have issues.

If you use Nam in a project, I'd appreciate it if you mentioned it on the Projects wiki page.

Nokurn wrote:I got pissed at my previous asset manager last night and got rid of the whole damn thing.

I totally thought "asset manager" was a person for a moment there..

Alright, I fixed it somewhat. There's a bug that causes shit to go crazy if the nam::store is cleared/destroyed before all of its nam::shared_ptrs, which I'm working on now. Aside from that, it's usable as far as I'm aware.

dandymcgee wrote:

Nokurn wrote:I got pissed at my previous asset manager last night and got rid of the whole damn thing.

I totally thought "asset manager" was a person for a moment there..

Edit: Ok, I've ironed out all of the bugs I was aware of. I'm using this in a project that I'm actively developing, so I'm testing it as I go. If anyone else uses it and finds a bug, let me know!

I'm curious, from the WIKI I am unsure how one would be utilize NAM. Could you post an example of what benefit it is providing you?

From the basic usage tutorial, it seems you write a class that writes and reads a file, and it returns to you, the user, a shared_ptr<T> (T is the type you just wrote) for the file you just wrote, which exposes the methods you (the user) just wrote... What benefits are you getting from using NAM? What code does it prevent the user from writing? That said, I do have to compliment your style and am curious to see what your answers are.

short wrote:I'm curious, from the WIKI I am unsure how one would be utilize NAM. Could you post an example of what benefit it is providing you?

From the basic usage tutorial, it seems you write a class that writes and reads a file, and it returns to you, the user, a shared_ptr<T> (T is the type you just wrote) for the file you just wrote, which exposes the methods you (the user) just wrote... What benefits are you getting from using NAM? What code does it prevent the user from writing? That said, I do have to compliment your style and am curious to see what your answers are.

The wiki definitely needs improvement, there are some things that could be clarified. I'll work on it this weekend.

Say you've got a lot of textures in your game that are used in multiple places. Both in terms of memory and speed, you're better off maintaining a single copy of that texture until it's no longer in use. That's what nam::store does. It keeps a map of nam::internal_ptr objects that are keyed according to your texture type (let's call it mg::texture2)'s key_type (in this example, a std::string that represents a filename). You load textures through a shared (possibly engine-wide) nam::store<mg::texture2>. When you call the get() method or use the non-const [] operator, the nam::store will search for an existing texture that matches the key you requested. If no texture with that key is found, it's loaded using mg::texture2's constructor that takes a mg::texture2::key_type. The method returns a nam::shared_ptr<mg::texture2> for that texture.

nam::shared_ptr will do reference counting on the texture's nam::internal_ptr. When the nam::shared_ptr is constructed, it adds a reference; when it's destroyed, it removes a reference. Once the nam::internal_ptr reaches 0 references, it destroys itself and resets all associated nam::shared_ptr objects.

Future features I'd like to add are explicit caching (manually adding/removing references), nam::store iteration, and possibly some variants of nam::store that are optimized for specific uses. I'm also willing to take suggestions (and patches to implement those suggestions)

I will definitely have to give this a go next time I start an OpenGL project. Thanks for sharing.