Forums | NoesisGUI

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?

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

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?

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()?

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).

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?

3) Noesis::GUI::SetPlayAudioCallback
- maybe not a problem because we can specify user?

Not sure about this on your scenario. Are you expecting to have two different audio subsystems?

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)).

We have plans to implement an alternative to these global functions and pass the provider at LoadXaml time, something like:

Noesis::GUI::LoadXaml("MainWindow.xaml", xamlProvider, textureProvider, fontProvider);

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 have many doubts that I need to understand more, like

• Are the two instances of Noesis running in different threads?
• Are the two instances of Noesis using a different RenderDevice?

But we definitely should have a call to understand more about your scenario. Could you please send us an email?

Thank you!

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?

Thank you for the context.
In this case the editor plugin is also different, plugin is completely isolated (or we mean it to be) from the game.

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.

That sounds like a great solution.
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.

3) Noesis::GUI::SetPlayAudioCallback
Not sure about this on your scenario. Are you expecting to have two different audio subsystems?

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.

We have plans to implement an alternative to these global functions and pass the provider at LoadXaml time

Great to hear. Is there a ticket / request I can watch to get progress updates on this?

Are the two instances of Noesis running in different threads?

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 using a different RenderDevice?

That's hard to tell right now, plugin uses `UnityGraphics->GetRenderer()` but game can do whatever.
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.

But we definitely should have a call to understand more about your scenario. Could you please send us an email?

Will do shortly. Thank you.