For our big project Doom & Destiny 2 i have created a content update/distribution system based on the azure cloud service.
Since part of the game assets are downloaded from the cloud i’m trying to extend the ContentManager to read assets from outside the default locations. While i was trying to do it by only overriding methods of the default CM, like the OpenStream method, i found that some of the raw content readers are forced to the TitleContainer as a way of opening streams. So my doubt is : what is the best approach to extend the functionality of the CM without “touching” the Monogame Source?
Should i copy the contentmanager.cs to my project and modify it from there ?
1 Like
Can you give a specific example?
What do you mean by “raw content readers”? MonoGame has always intended to remove support for reading “raw” assets through the ContentManager. In other words, only compiled XNB files would be supported. I believe that if you are overriding ContentManager.OpenStream, you should be able to read in any XNB file saved remotely that would normally work if it was saved locally, all without modifications to existing MonoGame source.
Well, i just noticed that the ReadRawAsset in the new version is marked virtual, this makes the overriding smoother and painless…
So actually my doubts were on methods similar to this, inside ReadRawAsset.
using (Stream s = TitleContainer.OpenStream(assetName))
return SoundEffect.FromStream(s);
when i was expecting something similar to s = OpenStream (wich in turn can be overridden)
But if i can override the whole ReadRaw i’m absolutely done.
ContentManager.ReadRawAsset will be removed soon. It was simply a stop-gap measure while we got our content pipeline sorted out. Raw assets should be loaded through functions such as SoundEffect.FromStream, Texture2D.FromStream, etc.
Interesting discussion. Are you saying, loading assets for example like this:
texture2DToLoad = new Texture2D(graphicsDevice, pic.sizex, pic.sizey);
texture2DToLoad.SetData<uint>(data);
will be unsupported in future builds? Just checking.
That is not loading a raw asset through the ContentManager. That is creating a resource in code, and will remain unchanged.
What will be removed will be the loading of PNG and WAV files, for example, directly through the ContentManager. All assets loaded through the ContentManager would have to be processed by the content pipeline tool at build time. Raw files such as PNG and WAV are to be loaded through the FromStream static methods in SoundEffect and Texture2D.
2 Likes
Hi,
I’m interested in the same asset loading strategy.
Did you manage to easily patch it and, by any chance, are you able to share them?
Thanks
At the moment i’m still using a hack in the source of monogame… I’ll be working on a neutral implementation as soon as i have half a day available.
Unfortunately as i am looking the code it seems like there is a big issue into extending the current contentmanager to find non xnb files outside the TitleContainer: after catching the ContentLoadException for not finding the XNB a non overridable assetname = TitleContainer.GetFilename(Path.Combine(RootDirectory, assetName)); is called to get the raw file path inside the TitleContainer. If we want to find files elsewere we might as well override the whole Load method…
It would be cool if the contentmanager would check if the path given already has an extension or is already rooted and in that case could fallback directly to a raw content reader to the rooted path specified…
Yes, loading non-xnb files through the content manager was a hack from the early days of MonoGame and it’s not “supported”. So, to ensure you can remain compatible with future MonoGame versions you must either:
- Only store xnb files remotely and override OpenStream(), or
- Store your raw asset files remotely and load them using Texture2D.FromStream() (or equivalent).
Good luck!
[EDIT] or 3. Roll your own ContentManager implementation 
1 Like
Helpful indeed. Thanks! 
I’m looking forward to the audio compression engine, once it is done i will switch to full xnb only… till now i have to resort to hacks and superhacks to stay in the 50 mb range…
Maybe redesign TitleContainer.Location?!