Two Noesis(s) in a game
Hello,
I'm wondering if we can start a conversation about what it takes to run two distinct Noesis instances within a game .. or if not possible, what are the exact calls that need to be shared.
We're running into an issue where a game using Noesis for their UI is using a plugin for part of a functionality that has it's own UI written in Noesis
ex/ steam in game overlay in Noesis over a game also in Noesis.
Plugin does not expose any Noesis knowledge to the game, we'd very much like to keep that if possible.
Things we found so far that definitely conflict:
1) In Unity/C# this code will prevent loading of one set of xamls, we're not sure yet how to reconcile it:
[ScriptedImporter(1, "xaml")]
public class XamlImporter : ScriptedImporter
2) Shutdown logic. Noesis::Shutdown() cannot be called until both are ready to shutdown, also one can't call Noesis::Shutdown() and have next instance init new Noesis as needed
2.1) or do you expect Noesis::Init() to work correctly when called after Shutdown()?
Possible conflicts:
3) Noesis::GUI::SetPlayAudioCallback
- maybe not a problem because we can specify user?
4) Noesis::GUI::SetXamlProvider / Noesis::GUI::SetTextureProvider / Noesis::GUI::SetFontProvider
- not a problem if one uses embedded and other doesn't, but I don't know if it's a problem if both game and plugin will use same provider types (say ManifestXamlProvider(s)).
I'm wondering:
5) What else can you think of that can go wrong when using two Noesis(s)?
5.1) Is there a plan to allow for multi instance?
6) What are some recommendations you may have for sharing single Noesis instance?
I'm wondering if we can start a conversation about what it takes to run two distinct Noesis instances within a game .. or if not possible, what are the exact calls that need to be shared.
We're running into an issue where a game using Noesis for their UI is using a plugin for part of a functionality that has it's own UI written in Noesis
ex/ steam in game overlay in Noesis over a game also in Noesis.
Plugin does not expose any Noesis knowledge to the game, we'd very much like to keep that if possible.
Things we found so far that definitely conflict:
1) In Unity/C# this code will prevent loading of one set of xamls, we're not sure yet how to reconcile it:
[ScriptedImporter(1, "xaml")]
public class XamlImporter : ScriptedImporter
2) Shutdown logic. Noesis::Shutdown() cannot be called until both are ready to shutdown, also one can't call Noesis::Shutdown() and have next instance init new Noesis as needed
2.1) or do you expect Noesis::Init() to work correctly when called after Shutdown()?
Possible conflicts:
3) Noesis::GUI::SetPlayAudioCallback
- maybe not a problem because we can specify user?
4) Noesis::GUI::SetXamlProvider / Noesis::GUI::SetTextureProvider / Noesis::GUI::SetFontProvider
- not a problem if one uses embedded and other doesn't, but I don't know if it's a problem if both game and plugin will use same provider types (say ManifestXamlProvider(s)).
I'm wondering:
5) What else can you think of that can go wrong when using two Noesis(s)?
5.1) Is there a plan to allow for multi instance?
6) What are some recommendations you may have for sharing single Noesis instance?
Re: Two Noesis(s) in a game
That's for the editor only, for importing XAML. I understand that even in the case of using Noesis twice in the same game, the editor plugin will be the same?1) In Unity/C# this code will prevent loading of one set of xamls, we're not sure yet how to reconcile it:
[ScriptedImporter(1, "xaml")]
public class XamlImporter : ScriptedImporter
Our current Init/Shutdown protocol is a bit weak because our reflection is based on global statics that allocate memory. Once you free this memory (at Shutdown time) these statics cannot longer be used or reinitialized (related to #2193).2) Shutdown logic. Noesis::Shutdown() cannot be called until both are ready to shutdown, also one can't call Noesis::Shutdown() and have next instance init new Noesis as needed
2.1) or do you expect Noesis::Init() to work correctly when called after Shutdown()?
Changes here are not easy, but I think we could implement a counter to only do Shutdown when the total number of Init minus Shutdown equals zero. So this would work:
[Plugin] Init() => Noesis Init happens here
[Game] Init()
[Game] Shutdown()
[Plugin] Shutdown() -> Noesis Shutdown happens here
What do you think?
Not sure about this on your scenario. Are you expecting to have two different audio subsystems?3) Noesis::GUI::SetPlayAudioCallback
- maybe not a problem because we can specify user?
We have plans to implement an alternative to these global functions and pass the provider at LoadXaml time, something like:4) Noesis::GUI::SetXamlProvider / Noesis::GUI::SetTextureProvider / Noesis::GUI::SetFontProvider
- not a problem if one uses embedded and other doesn't, but I don't know if it's a problem if both game and plugin will use same provider types (say ManifestXamlProvider(s)).
Noesis::GUI::LoadXaml("MainWindow.xaml", xamlProvider, textureProvider, fontProvider);
I have many doubts that I need to understand more, like5) What else can you think of that can go wrong when using two Noesis(s)?
5.1) Is there a plan to allow for multi instance?
6) What are some recommendations you may have for sharing single Noesis instance?
- Are the two instances of Noesis running in different threads?
- Are the two instances of Noesis using a different RenderDevice?
Thank you!
Re: Two Noesis(s) in a game
Thank you for the context.That's for the editor only, for importing XAML. I understand that even in the case of using Noesis twice in the same game, the editor plugin will be the same?
In this case the editor plugin is also different, plugin is completely isolated (or we mean it to be) from the game.
That sounds like a great solution.Changes here are not easy, but I think we could implement a counter to only do Shutdown when the total number of Init minus Shutdown equals zero.
I suspect there won't be a case like this often: Plugin Init() > Plugin Shutdown() > Game Init() > Game Shutdown(). Or you can very much specify that in your integration docs and we'll make sure it doesn't happen.
There would only be one audio subsystem, we fully expect game teams to set callbacks but we also fully expect the callbacks to our plugin to be indirect / go through some layer that isn't game UI. We likely have other ways of handling this, maybe with a "request play audio" call from us and not a direct audio system call.3) Noesis::GUI::SetPlayAudioCallback
Not sure about this on your scenario. Are you expecting to have two different audio subsystems?
Great to hear. Is there a ticket / request I can watch to get progress updates on this?We have plans to implement an alternative to these global functions and pass the provider at LoadXaml time
I couldn't guarantee that we'd run on same thread, so I'll say yes (likely different, unless we know we need to be on same thread, then we can try to work with that).Are the two instances of Noesis running in different threads?
That's hard to tell right now, plugin uses `UnityGraphics->GetRenderer()` but game can do whatever.Are the two instances of Noesis using a different RenderDevice?
Though as part of solution if a RenderDevice could be passed through from the "first" Noesis, and that's how we need to work with it then sure.
I would only ask if then we are version locked .. as we fully expect two Noesis(s) to be on different versions.
Will do shortly. Thank you.But we definitely should have a call to understand more about your scenario. Could you please send us an email?
Who is online
Users browsing this forum: Bing [Bot], Google [Bot] and 49 guests