Has anybody seen/tried to interop with this gui lib and monogame yet?

I just ran into https://github.com/AvaloniaUI/Avalonia and immediately thought it might make a good candidate for use with monogame.
From what I can tell, it’s the community-driven, crossplatform xaml-based gui we’ve all been waiting for.

I was just wondering if any of you have tried it out (and if so, maybe tell me how it is :slight_smile: ) .
Also if anybody who indeed has used it, has any idea on how well it would play with MonoGame, that’d be great to know too :smiley:.

As a side-bonus, I’m pretty sure it’s the first GUI library that runs under .Net Core. So that’s cool too I guess.

From the little knowledge I have on the subject, if this new GUI is XAML based than you would not be able to use it in a standard MonoGame application since MonoGame uses Windows Forms as its base.

As a result, you would have to host the MonoGame environment within an XAML application.

I could be wrong but so far that is what I have been seeing on the forums concerning this type of mixture.

Looks like Avalonia supports a bunch of back ends including WinForms, GTK, Skia and Cairo. So it’s probably possible to get it working with MG. It looks very promising IMO! Might need to use reflection or modify source to get some native window handles or whatnot from MG.

Two things, Jjagg…

WinForms, XAML and the like are “front end” support infrastructures.

I also tried to take a look at the samples page that described support for multiple front-ends but that link appears to not work.

I do not see how a GUI can support different front-end display functionality. XAML is Windows Presentation Foundation, which relies on XAML markup for the display. WinForms on the other hand, relies on internal object definition for display components.

What the author of the software may have meant by the support for multiple front-ends is the ability to use the differing components of each front-end style in a cross-platform way as XAML and WinForms are already capable of to some degree. However, this does not mean it will mesh well with the MonoGame window.

I could be wrong on this but so far the documentation for the software is rather nonexistent so we will have to wait and see…

I personally haven’t done much gawking at Avalonia’s code yet.
As soon as I have time I may try to hack something together.
It’d be great to have this though.

Why not write it in as a monogame backend with additional exposed functionality? Would there be any problems with that?
Like a AvaloniaGameWindow or whatever naming convention they use :D.

Shows embedding Avalonia controls within a winforms window. But it errors out in my test bed.

protected override void Initialize()
{
    base.Initialize();
    WinFormsAvaloniaControlHost host = new WinFormsAvaloniaControlHost();
    host.Content = new Avalonia.Controls.Button();
    var form = System.Windows.Forms.Control.FromHandle(Window.Handle);
    form.Controls.Add(host);
}

Throws up an Exception with the message “Could not CreateEmbeddableWindow(): IWindowingPlatform is not registered.” for me.

If you are looking for XAML based UI, you can use Empty Keys UI. It’s much more powerful compared to Avalonia.

Info: http://emptykeys.com/ui_library
Nuget: https://www.nuget.org/packages/EmptyKeysUI_MonoGame/

1 Like

XAML is just the markup language. Basically Avalonia (and Empty Keys UI) let you define your UI’s in XAML like you would for Wpf.

Avalonia implements its functionality based on low level operations provided by other libs. It can use either Skia, Cairo or Direct2D for rendering I think. It can also handle multiple windowing libs (at least Win32, not sure about others). Because the API of Avalonia abstracts those away and provides a unified interface on top of them I call them backends, similar to how MonoGame can use DirectX or OpenGL and we call those the graphics backends or WinForms/SDL for windowing and we call those the windowing backends. I was wrong to say WinForms was a backend for Avalonia though. They don’t use it for windowing, they just provide some classes for interop.

1 Like

I got past my other exception by setting up the application as in the program.cs of the sample code I linked to previously.
However somehow I wonked-up monogame. It spits out a Microsoft.Xna.Framework.Graphics.NoSuitableGraphicsDeviceException with a message of TypeLoadException: Could not load type 'SharpDX.Rectangle' from assembly 'SharpDX, Version=4.0.1.0, Culture=neutral, PublicKeyToken=b4dcf0f35e5521f1'. And now this is occurring on all of my monogame projects.

What have I done!?

Also, in addition to the win32 windowing system, it support gtk3 with custom p/invoke bindings I believe.

Also filcon, I use EmptyKeys in some of my projects. But I have no problem with exploring other options of course.

NoSuitableGraphicsDeviceException is thrown by MG when initialization of the GraphicsDevice fails, regardless of what caused it. The inner exception shows the real problem. I think the issue is Avalonia uses another version of SharpDX and it causes some conflicts.

Yeah, I feared it might be a dependency-version mismatch.
Still though, I’m going to try to get this working.
Maybe my best best would be to write a monogame renderer for Avalonia.

Thanks!

Hi Jjagg…

As you may be showing in your notes what you are calling back-ends may be different from what I was trained in within the business aspect of the IT profession. This could be how the gaming development community sees things.

However, a back-end to me is any support construct that provides data access support such as an RDBMS or a Message Queue.

Middle-Tiers are considered the layers that provide all the computations required by an application or the calls required to support requests or updates to data servers.

Graphic components such as MonoGame and the like would be considered middle-tiers since they do not support (in general) the acquisition or the manipulation of actual data in any way. However, they do provide graphic computations and interfaces to the necessary hardware components such as you mentioned like a GPU.

Even in a multiplayer game where a server is required, graphic operations would still be considered a middle-tier component since the basis of such components would reside on an application server (not a database server) or within the component structure of the front-end.

Front-ends are considered any component that provides interface support even if they are generated at the server. For example with ASP.NET WebForms where you use server-based controls, the markup for these controls that you implement into a web-page generate all of the extensions necessary at the application server tier. Nonetheless, technically all of this is considered front-end support.

I think we are just seeing things the way we have been primarily trained in development. :relaxed:

1 Like

Hello, Avalonia dev here.

You can use the framework on top of almost anything (we even have basic support for rendering directly to Linux’s /dev/fb0).

To do that you need to implement so-called “toplevel” - https://github.com/AvaloniaUI/Avalonia/blob/master/src/Avalonia.Controls/Platform/ITopLevelImpl.cs and a suitable “surface” for rendering. The most basic surface is ILockedFramebuffer which is basically a pointer to unmanaged memory with bitmap data. It’s technically possible to wire up Direct3D texture or OpenGL FBO, but that would be much harder task.

Contact us in gitter chat if you have any questions.

2 Likes

Thanks, kekekekekekekeks. I haven’t had the time yet. But rest assured when I do find the time, I’ll try to implement the toplevel and surface for monogame. I’ll update the original post with a github link when I finish it too.

Did anyone take another look into this or make any progress with this.

Update on this topic. I dont know of an existing example but I think i konw how to make one, however i don’t need it this year myself and don’t have the time.

WPF / windows MG Sample by Craftwork game , that shows a good way how to do this in WPF, or maybe Avalonia on the Monogame side at least, and combined with kekekeks direction , would tell how to do this for Avalonia via OpenGl MG, instead of the SharpDX, but with the game general idea.

This is how it was done before but its not been maintained, it broke with MG 3.8.1 but its fixed now, just not merged… The source code says how to do this on the Monogame side a

( Mine and another guys PRs got WPF net6 Windows / Monogame, now working on the latest Net6.Windows , Net6 Game Dlls , and MG 3.8.1… no major issues. WPF.Net6 -is- open source but theres no near term plan to make it work on GL or non windows. So this not the full answer for multiplatfrom WPF and MG surfaces, but its a proof of concept.

So i put its source in my EXE project, Net6 .Windows, merge both prs and the old one works at least for windows. here are the PRs Pull requests · craftworkgames/MonoGame.WpfCore · GitHub. sharpDX is dead and archived and i luckily didnt have to dig into it. But openGL works on windows as well soooo…

But this old thing can show the Monogame side of things and how to set up Graphics device service…
https://github.com/craftworkgames/MonoGame.WpfCore/pulls

This might give a direction how to do it in in avalonia as kekekeks has pointed out the general direction:

But then you need a shared and locked surface fo rthe rendertarget, and an OpengL one would make sense.

But like you , i would like other platfroms too. And Maui , Xamarin, UAP are all dead, nonstarters, ( my opinion on Mauii) or gonna be killed soon. WPF is undead. Avalonia Lives… Silk is rising , has Windowing and generalized Input and mabye those GL bindings will help with this as well as replacement for SharpDX via open GL, then try and use MonogameGL on everything,windows supports it.

So the basics is in the source in the aforementioned vault. it sets up a GraphicsDevice Service for Monogame via interfaces.

Then the hard part, setting up the shared buffer but that is what kekekek is pointing out, and there is a interface to the device window handle too in Avalonia.

#nullable enable
private void OnRender(object? sender, EventArgs e)
{
_gameTime.ElapsedGameTime = _stopwatch.Elapsed;
_gameTime.TotalGameTime += _gameTime.ElapsedGameTime;
_stopwatch.Restart();

    if (!_isFirstLoad && CanBeginDraw())
    {
        try
        {
            _direct3DImage.Lock();

            if (_renderTarget == null)
                _renderTarget = CreateRenderTarget();

            if (_renderTarget != null)
            {
                GraphicsDevice.SetRenderTarget(_renderTarget);
                SetViewport();

                _viewModel?.Update(_gameTime);
                _viewModel?.Draw(_gameTime);

                GraphicsDevice.Flush();
                _direct3DImage.AddDirtyRect(new Int32Rect(0, 0, (int)ActualWidth, (int)ActualHeight));
            }
        }
        finally
        {
            _direct3DImage.Unlock();
            GraphicsDevice.SetRenderTarget(null);
            _viewModel?.AfterRender();
        }
    }
}

. You draw calls go to a a rendertarget, and mabye be limited to the 60 fps…

But using producer consumer you can run your game update/ simulation/ AI code at any rate you want on background threads.

So to do this would require using Monogame , GL, taking the craftwork code, and
porting it to GL as shown in Silk or in Avalonia, and hooking it in there via kekekeke direction.

mabye some of MarkStans code if you want to handle input via Monogame, i abstract that out… ) better to use Silkon this if you needed it. Other triicks that might help on this in the EmptyKeys ( but that is not maintained, its using Netstandard 2.0) which MG has dropped support for.

Not easy but doable.