Launch a Xenko game from a different thread, in a different program

#1

Hello,

I am wondering if it would be possible to use just the DLL of a Xenko game to launch a Xenko game from a secondary thread started from a different program, let’s say Maya or 3ds Max.

The idea is to have a Xenko game and visualisation package running simultaneously in a non-blocking fashion while sharing the same process.

Let’s assume that a modelling package (such as Maya or 3ds Max) have a plugin system that would allow me to load and run plugins in .NET C# (even if these packages do not support .NET is it not relevant here, it is just to illustrate my problem with tool everybody is aware of).

And let’s assume that, from the code of the plugin loaded in the package, I am starting a secondary thread and launch the Xenko game as follows:

using (var game = new Game())
{
     game.Run();
}

Do you guys think that the game would be allowed to run ?
Do you see any reason why that would may fail and how to make it run ?

I would also like to mention that this scenario would be for Windows only, so that the internal game window could be a Winform window instead of a SDL.

Also the game that I want to develop would be for VR so I do not be all the Desktop input Jazz such as mouse or keyboard since I will be getting all the input from the controllers.

Thanks in advance guys for your input.

#2

As far as I am aware, this is possible or this was when I played around with it.
I may be wrong tho.

The easy way to test is to make a new Task with a delegate starting the game? :slight_smile: (I got it running in a WPF app, so it’s probably possible)

#3

Agreeing with Hayaweh here. The game.Run method takes a GameContext parameter that you can use to specify where Xenko sends it’s frames. I can’t imagine creating a VR context is too hard, though I’ve not looked it up.

In your scenario your host app would launch, setup the correct context and then boot Xenko. I actually think at this point Xenko is really well suited to being an embedded engine.

Although to be honest there are rare situations where you have a host app AND a VR session so that is slightly odd. Unless you’re creating a design app, but remember, people don’t like hopping in and out of VR. I know it drives me mental. :wink:

#4

Task is for micro-threading mate, it’s not actually starting another thread…

#5

Task.Run starts a task on another thread from the ThreadPool https://docs.microsoft.com/en-us/dotnet/api/system.threading.tasks.task.run?view=netstandard-1.6

1 Like
#6

As dfkeenan said just above. Not really. It’s just a system managed directly by the system to avoid you creating a new thread manually etc… Basically it’s “better” to use as far as I know in most cases.
I mean. I did it in a WPF app. So, yeah, I know this works. :slight_smile:

#7

@matmuze If I’m remembering correctly, Unity used the Task class for their custom micro threading implementation. System.Threading.Task is not the same.