Few ContentManager questions

You have few items to load, so it currently works because the thread is faster than the part asking for a loaded resource, but what happens if your LoadGame() method takes 10s or more ?
I think it is missing a synching mechanism.
Something like a Manual or AutoResetEvent at the end of LoadGame() to signal the main thread it has finished its job.

@Alkher, I don’t need a synching mechanism because I’m using a screen system and I change the screen to the main menu screen at the end of LoadGame(). I’ve simulated a long time (50 seconds) load with Thread.Sleep() in the LoadGame() method and it works as expected.

And I’ve much more resources to load, sounds, songs, spriteFonts, etc. I just shown here a small piece of code to show the idea.

I think that @raizam will probably need a synching mechanism.

Thank you for your suggestion.

You’ve guessed right, I’m currently working on it :slight_smile:

I’m using the .NET Task Parallel Library for asynchronous operations, it much easier to work with it.
I will probably share some code later on

1 Like

I think I have something sharable: https://gist.github.com/raizam/df2f62801ab989dbb55226d911dd917f

This makes threading in Monogame easier.
I’ve created a TaskManagerComponent, which is a regular GameComponent, this is used like this:

    //In your game class

    Color clearColor = Color.CornflowerBlue;
    protected override void Initialize()
    {

        TaskManagerComponent  taskManager = new TaskManagerComponent(this);
        Components.Add(taskManager);


        taskManager.ExecuteInBackground(() =>
        {
            Thread.Sleep(2000);

            //ThrowIfNotInGameThread(); //this throws here

            return Color.Aqua;
        }).Then(task =>
        {
           
              ThrowIfNotInGameThread();  //Here we are back in the game thread, inside Update()

            // 'task' is a Task Parallel Library result instance: Task<Color>
            clearColor = task.Result;

        });


        base.Initialize();


    }
1 Like

I’ve read somewhere that GameComponent and DrawableGameComponent should be avoided. Verify this if you have a chance.

This is very vague… If you like the way they work you can use them, there’s nothing inherently wrong with the component system.

So you throw an exception to sync between the task(s) and the game’s thread ?

He just put that there to show that the code runs in the main game thread. When the GameTasks internal task finishes it puts the ‘Then’ task in a queue in its TaskManagerComponent. When Update is called on the TaskManager (on base.Update in Game through the component stuff) it executes whatever is in that queue (on the same thread).

I don’t know where you’ve read that, but in fact… GameComponents are awesome :grinning:
It encourages separating logic in small units that each have its own role, and each of these behavior can be added or removed depending on the need, hence this helps reusability.
The concept of Separation of Concerns is the key of a good architecture.

As Jjagg points out, this is just to prove that the result of the background operation is passed back to the game loop: because no exception is thrown, it passes the test. This means we are safe with synching concerns. The only thing you can do wrong here is to use instances that belong to the game thread inside ExecuteInBackground, don’t do that =)

Sorry guys I think I didn’t read the whole post about avoid using the DrawableGameComponent. Here’s where I read it.

Thank you @Jjagg for your explanation.

I think I’ll use them :slight_smile:

Not sure how he got 20 votes, his points aren’t convincing, and his examples are futile. This contracdicts what’s currently happening in the software industry. The history of software architecture is quite young, the evolution could be pictured as: spaghetti -> lasagna -> ravioli

When I started my career, we were told that the lasagna architecture was the best, (N-Tier architecture)…
But in practice everyone realized the lasagna approach is not so efficient, too many layers and it was too much maintenance. Then the ravioli (Components) approach emerged, and this is AFAIK still the dominant paradigm today.

Unity is massively based on component, and it looks like it’s working well, they could build a big ecosystem, everyone is using components made by others, and everything is pluggable. I haven’t tried UE4, but I’m pretty sure it has a component-based architecture too.
So, what this guy say is not what’s happening in ‘the real world’ as he says.

@vcRobe in the stackexchange link you’ve provided, there is another answer contradicting the accepted one, which has more vote. Since you believe whoever has votes, maybe he can convince you :slight_smile:

There is an old thread from 2007 in the Ogre forums about components: http://www.ogre3d.org/forums/viewtopic.php?t=36015. This is pretty much when the Component pattern started to be a thing, that’s an interesting read.

I think you both already achieved a consent with his last post.
So as far as I can tell, everyone here shares the same opinion.
:slight_smile:

haha. that’s why I need to sleep sometimes :dizzy_face:
that’s nice =)

Nah… Sleep’s overrated.
:smile:

1 Like

@raizam, I know that components are the way to go in fact the first time I saw the GameComponent and DrawableGameComponent classes I thought “what a good idea!” but a few weeks after that I read that post and I thought that he said that because Microsoft will remove those classes from the XNA. I read that post a long time ago that’s why I told you in my first reply

In fact yesterday I was reading the XNA demo ParticleSample_4_0.zip (a 2D particle engine) and it was written as a DrawableGameComponent. I’ve separated the particle systems to a new class library project so I can use it in any game writing a very few lines of code. If somebody is interested in the demo I can share the code. I ported it to VS 2015.

Well… I think I learned something new today :slight_smile:

Thank you guys.

hehe no worry @vcRobe. I know that I also tend to overeact with these kind of discussions, I tend to be too passionate =)

I’d be interested indeed! Especialy that the particule engine from Monogame.Extended, while looking very well done, isn’t implemented as a component. and I’d like to see how they compare.

Here’s the 2D particle system that I ported to MonoGame. I did minimal changes to the original

Here’s a 3D particle system from the XNA community. This is more advanced because it uses HLSL to animate the particles. I tried to port it to MonoGame but for some unknown reason the particles aren’t displayed (they’re displayed in the original project using XNA) but I don’t know how HLSL work so I gave up (for now). It’s a DrawableGameComponent too.

I Hope this help!

Hey @vcRobe,

About the 3D version, I’ve read somewhere here about someone that was having hard times to port his HLSL effect from XNA to Monogame (can’t find the thread) but in the end he could resolve it by changing the way he assigns the uniform parameters.

So he was able to solve it by replacing from:
effect["parameterName"] = value;
to
effect["parameterName"].SetValue(value);

hope it helps

I checked all the parameters of the effects and all are set with .SetValue()