This project is read-only.

new to the asset manager

Nov 4, 2009 at 11:29 PM

I'm pretty unawre on how content manager in xna works. Can you enlight me on what does your content tracker?

If undertsood it right, it allows you to load and removed individual content and also threaded loading. So this is just a way to import and delete content ? Is there a real gain in term of power ? I'm sorry if my question sound really basic but I really didn't get it and I'm looking for a different way of optimising my game.


Also in your demo you load content on the fly, is it a feature of your content tracker ? Is this more suited to be in an editor ?



Nov 5, 2009 at 1:12 AM

Hi sueds, thanks for the questions. You do understand correctly: ContentTracker allows you to micro-manage your content, but it will not provide any faster loading than the default ContentManager.

It overrides ContentManager's protected ReadAsset<T> method which will get called every time an asset is read from disk. This means that when you call Load<Model>(...), the ContentTracker knows that your Model references various Texture and Effect objects (because internally ReadAsset is called on them) and allows you to interrogate these relationships. It also needs this information to provide the individual content item removal feature: For example, when you remove Model A, it will only remove it's textures and effects if they are not referenced by any other models. This is called reference counting.

As for the threaded loading feature, this is not unique to ContentTracker. Many games will use ContentManager to load their content on a seperate thread. The real feature is when you combine it with individual content removal. The idea (as shown in the demo) is that you can have a world that continuously streams it's content from disk, whilst also continuosly removing content that is no longer needed. To get the same effect with ContentManager, you'd need to wrap each world chunk in it's own ContentManager and call Unload() to remove it, but this would also mean that any world chunks could not share their assets - if they wanted the same texture they'd have to each have a copy in memory.

ContentTracker does lend itself for use in an editor (on windows), not so much because of the threaded loading but because of the individual asset removal, and another feature: Source Asset Loading. On windows, this allows you to bypass the XNB files altogether and directly read X file models, Xml files and Textures from disk.

If you want to read more about the internal workings of ContentTracker, the article on ziggyware is the best bet (

Feel free to ask any more questions you have about ContentTracker.





Nov 5, 2009 at 3:45 AM

sound like fun and really interesting. I just red the article and I'm planning to use it. Are you still planing to create the subclass to check the content ?

So if I understand it right the main advantage of content loading on demand is to stream all the content, and load them when it's needed, like for example in god of war. 

I didn't notice the demo file but this system seems really interesting. Do you have any advice or thing that I should be careful of ?

in term of memory and speed this should help a lot, have you doen some test ?




Nov 5, 2009 at 9:51 AM

I had actually forgotten about that windows only content tracker/builder idea - I ended up going down the Source Asset Loading route for my current game so the artists didn't have to build the content at all. This meant we were restricted to using only X files, textures and XML files with no custom content processors, but it worked out OK.

The idea for the content tracker/builder would involve subclassing ContentTracker and using the ContentBuilder code from Winforms Series 2 sample from the creators club site. To watch for changes in the content you'd use Eventually I may implement it myself, but not for at least a few months yet.

If you want to create a continuous streaming world, there are a few issues you'll come across. Even on a second thread, the GPU gets stalled when a large vertex or index buffer is created. This means you'd need to keep your model files small and possibly do some trickery so they don't all get created at once. Another large issue is that loading content will create garbage which is the enemy of all XNA Xbox programmers. Sooner or later the garbage collector will kick in and you'll get a momentary freeze. I'm pretty sure this is unavoidable. The only way to avoid garbage is to pre-load absolutely everything, which is obviously not compatible with a continuous streaming world :(