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 ) .
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 .
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.
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.
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…
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.
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=22.214.171.124, 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.
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.
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.
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.
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…
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.
. 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.