Unload single item from content manager

Content
1

how do i unload single item from content manager? does it practical? i am looking in runtime reload content function.

2

This is currently not possible outside adding a method to ContentManager and building from source. I made a pull request that adds this, but it has yet to be merged.

1 Like
3

You can create a custom ContentManager by extending ContentManager. Like the one shown here.

class MyContentManager : ContentManager
    {
        public MyContentManager(IServiceProvider serviceProvider) : base(serviceProvider)
        { }

        public override T Load<T>(string assetName)
        {
            return ReadAsset<T>(assetName, null);
        }
    }
3 Likes
4

I gave up on the Content Manager and just load stuff manually though it might only work on windows.
Code as follows:

FileStream fileStream = new FileStream(loadingName + ".png", FileMode.Open);
Texture2D texture = Texture2D.FromStream(Game1.GraphicsDeviceInstance, fileStream);

then later when you want to unload it you have to call:

texture.Dispose();

A lot of my levels have similar assets to the levels before and after them so being able to only unload and load what was required did a lot for my loading times.

1 Like
5

that only available to texture. im looking for general way to do it.

6

Okay well the other option Iā€™ve used is to make a separate content manager for each piece of content.

1 Like
7

Btw, thanks everyone!

8

Thatā€™'s the best approach IMO. With a good design this wont be much of a problem.
Usually in a game you will have a state manager with individual screens.
Each ā€˜Screenā€™ can have itā€™s own LoadContnent and itā€™s own ContentManager.
For example I have an IntroScreen that load and draw a texture for a few seconds, then the entire screen gets disposed when I move to MainMenuScreen.

9

This is approximately what Iā€™ve done too. I made a separate manager for each type of object, so I can unload it all at once when that thing is no longer relevant. With that approach in mind, Iā€™m surprised to say that I actually appreciated this design!

1 Like
10

As far as I understand the C# language, I donā€™t think this code is safe to use.

While it will remove the item from memory, it does not remove any pointers to it, which could cause null point exceptions.

This is because the way the content manager works, any time a part of the code wants to load the asset, (say for example, grass in a game, an object containing location and texture) it checks to see if it already has the asset. If yes, it just returns the pointer to the same asset. (pointer, pass by reference, asset is a generic, generics are classes, classes are only ever handled by reference). So say, I have lots of grass objects, and I go into a house, so I unload a scene, we have to make sure at no point does the grass object act on or off of the texture after it gets loaded, every object owning a pointer to the asset must remove that connection or the parent object must be deleted (disconnected and forced garbage collected, maybe even defragged by a second forced collection), or by some other trick make sure the texture is not used ever again, so that you can then unload the asset safely knowing that no other objects have fantom memories of the asset. Generally, the idea is not idiot-proof, that doesnā€™t make the code bad, but it does make it an issue.

Basically, you have to be smart and safe with the unloading.
You could modify the content manager such that it keeps track of all connections, and removes them when unloading, but that does not help with if an object wants to try to access the asset again for some reason in the code, unloading is generally not safe.

It seems the best work around is as poohshoes suggested

or better said

ā€˜Sceenā€™ being something akin to unityā€™s ā€œsceneā€ system
this is kinda safe. But that still requires users to design scene so that all the objects are destroyed as well. The only issue with this, however, is now you have to reload all assets, none carry over. A bit more load time at the risk of memory conservation. though I would also garbage-collect and defragment at this time as well.

1 Like