GUI Survey for 2022

Mine is designed for user-facing UIs and is open source. I claim that since components are coded on the game side. Components are also part of the update loop so can be animated or have any custom code. They are also part of the draw loop with access to the SpriteBatch.

I mostly just provide a sort of UI framework with ergonomics similar to IMGUI.

1 Like

I created a new GUI framework for myself , I couldn’t find something that I liked and that could fit my programming style, still working on it for the past 2 years and it is the most complex thing I ever wrote in my life, that’s why it is taking so long to make.
It has concepts of ImGUI plus retained mode at the same time for games and editors , it is a hybrid of both. Hope I can share something by end of the year.

2 Likes

Sounds interesting. Does it support the CSS box model with padding, margin, border and content?

There is also MonoGame.Extended.Gui

ImGUI looks really cool but it’s only for c++ right? I don’t understand how it could be implemented in MonoGame.

Pretty easy go to GitHub - dovker/Monogame.ImGui: An ImGui.NET wrapper for Monogame

Thanks. I’ve collected 3 MonoGame + ImGui project URLs now, plus a dead one:

I find ImGui more trouble than it’s worth. I’m constantly fighting things that wont scroll, items that appear out of bounds, floating windows that are responding to the wrong input, etc. Trying to do any sort of custom controls is pretty much out of the question as the work involved would be tremendous.

I’m all for Noesis creating an official port for MonoGame, but they wanted to see if people are interested, and according to my post Noesis UI - Do you want to see an official version supporting MonoGame? - General - Community | MonoGame, it doesn’t seem like people are :frowning:

1 Like

I have tried almost every UI framework I could find for monogame. GeonBit, Monigame.Extended, Xui, EmptyKeys, you name it. I finally settled Myra UI. For one main reason.

Everythig works as expected. There’s no lack of functionality. Besides one that I have found and that’s built in ToolTips. But that’s easy enough to build in. Besides that, it’s font rendering is smooth and clean, thanks to StashFontSharp. Its straight forward, to the point. Doesnt require any crazy setup. Comes with a editor, StyleSheets are easy to create, thanks to a built in texturepacker that spits out a texture atlas and a file that says where everything is thats read in by the framework automatically. Its been a real pleasure to use.

I originally settled on MLEM.UI but its font rendering didnt work just right and I didn’t want to spend the time to fix it.

But yeah, can’t recommend Myra enough. It’s great.

4 Likes

I can’t imagine anyone would want to use Myra over Imgui, however they are both Tool gui, neither has capability to create decently looking game gui, in the end you will always end up doing that yourself.

1 Like

I played a lot with Myra too, but I found little bugs with the stylesheets not containing the proper elements and having to investigate the code to hack things in. It’s a good choice for composing the UI in XML but it deviates too far from XAML for me, while investigating it I kept wanting more XAML systems in place and that was causing me frustration. Myra’s default style is definitely “tool” orientated, but there you can craft your own stylesheet and make a good game UI.

I then went on to play with EmptyKeys and that was probably the closest to XMAL, and one of the best options in my opinion, but it’s held back by a few things:

  1. It’s hard to get the generator working in your projects with MonoGame so that you can craft the xaml and generate the UI code when you run your project.
  2. The generator and tools are a few years old and using .NET Framework, which restricts the platform you can work on.
  3. The generator code is quite complex. I was looking for a way to add the ability to specify the x:FieldModifier XAML directive but it was just too much work to understand. .NET 5+ has added a lot of stuff for code generator projects, it would be awesome for this to move on from .NET Framework and into the modern C# world.\
  4. Events on controls don’t work like you would expect them to. They expect you to use command binding on everything.

But I still keep coming back to just wishing Noesis was MonoGame cross-platform as it would be a really easy way for me to build an in game editor for my game engine, without the complex hassle of ImGUI.

2 Likes

ImGUI is literally easiest to use, what hassle are you talking about? As mentioned above, it is used in production in high end companies, neosis on the other hand… you sure you aint Noesis salesman? Honestly, imgui is as comfortable as it gets, nothing comes close, Noesis is lightyears behind.

(I mean, I know you listed some issue, but I’ve integrated ImGui into three projects, one using MG, one FNA and one own rendering back end and never had single issue you mentioned, so it is bit complicated to take them seriously)

1 Like

SadConsole/GuiSurfacePreview.cs at master · Thraka/SadConsole (github.com)

This area is where I have tons of problems. I’m trying to render a texture2d game map which is grid based and have a floating tooltip box that displays information about the cell hovered. Also the texture area should be scrollable within its parent window, the window could have more controls in it.

Also, a docking system isn’t very good in the C# library library. I also have no idea how to preemptively set up the GUI system for an in game editor. It’s just too much work to figure it out if you don’t already know it like you obviously do.

When you know how to do things in ImGUI, you can do them. If you don’t know, you have to decipher C++ code and read through forum posts that all have access to the features hidden behind the ImGUI C# integration library, so you can’t tweak things the way you want or enable new things added to the library.

Again, it’s just too much friction for a hobby game dev.

I do think Noesis is awesome, and EmptyKeys is awesome too, it just needs some more love. Having binding/commanding systems is awesome and separating UI from code is a huge win for tweaking things without breaking things.

Just because I like, no, love a library doesn’t make me an employee. You sound like you have some weird hate towards Noesis. If I was an employee pushing for my product to be used, what is the problem with that? Don’t you think you’ve made an amazing game in Wayward Terran Frontier and want people to play it? Would you promote it to people in a forum about games?

3 Likes

When I promote WTF I do it as a dev, not as “hey guys, I am this completely independent person and I am saying WTF is awesome, zero bias guaranteed” (on not so relevant note, I am not sure when was the last time I’ve promoted WTF in any way). What I find weird is the whole context of what you are doing and how you are doing it. Bringing commercial gui framework to opensource game framework when saying it will become “go to for MG devs”? Come on…

About your problem: Texture area is render target, all you need for interaction is to get relative mouse position to canvas and then you find mouse hovered object as usual.

I do not believe that this particular task is in any way easier in Noesis. Anyway, what I find absurd here is that there is, as you said, existing c# wrapper for Noesis, so at that point why push it further. It’s easy to use, ey? I have hate towards shady stuff and pushing Noesis over Imgui for ease of use out of all things? That’s absurd in my book. Maybe if you would at least go with recommending Noesis but for a tool/editor over ImGui? Nope.

I’m a bit late to the party but here’s my GUI framework:

Open source, MIT license, supports box model, has a ton of controls. I’ve seen some frameworks only have the common stuff like buttons, checkboxes, textblocks etc but mine has a lot more than that. Heavily inspired by WPF so you’re intended to use it with a hierarchically defined UI so the layout engine can arrange everything for you, but if you really wanted you can still use absolute positions (by just dumping all your controls into an MGOverlayPanel with specific offsets for each one). If on Windows, it’s also able to parse a limited form of XAML markup. Like if you did this:

<Window SizeToContent="WidthAndHeight" MinWidth="200" MinHeight="100" Padding="16,12">
    <Window.TitleBarTextBlock>
        <TextBlock FontSize="9" Foreground="White" Text="An [b]MGWindow[/b] with a single [b]MGButton[/b]: [color=yellow]Click it![/color]" />
    </Window.TitleBarTextBlock>
    <StackPanel Orientation="Vertical" Spacing="10">
        <TextBlock FontSize="12" Text="Window Sample" HorizontalAlignment="Center" />
        <Button Name="Button1" Content="Click me" BorderBrush="Gray" BorderThickness="2" Padding="5" />
    </StackPanel>
</Window>

Then subscribe to the button’s event handler in your c# code:

Window1.GetElementByName<MGButton>("Button1")
      .AddCommandHandler((btn, e) => { btn.SetContent("I've been clicked!"); });

Would result in a window like this:
MGUI Button

You can use textures to fill things like borders or backgrounds so I’ve no doubt a motivated person with the right assets could make a pretty UI with the framework.

And just about everything is customizable. For example if you make a checkbox, you can override the style of the button part (where the check mark is shown) to make it look however you want. Hell you could even set the checkbox’s CheckMarkColor to Transparent, and subscribe to MGElement.OnEndDraw event to then render your own completely custom check mark.

2 Likes

Overall, MGUI looks great.

Can the back-end be re-targeted? I’ve been experimenting with using SDL2 directly.

What do you think it would take to get the fonts looking smooth like we see in web browsers? Often, the fonts I see in MonoGame and other game frameworks are pretty rough with either heavy pixelation and/or kerning issues.

Note that the two character prefix on classes is a bit strange for .NET. The normal thing is to use plain names (“Button” rather than “MGButton”) and then let the user make use of C# if they in fact want a prefix:

using MG = MGUI;

Or using MGUI; for no prefix.

I don’t know much of anything about other backends but the bulk of the drawing logic is funneled through MGUI/DrawTransaction.cs at master · Videogamers0/MGUI · GitHub . There’s also a dependency on MonoGame.Extended. Mostly for a few simple structs like RectangleF, Thickness, and Size, and some drawing stuff like MonoGame.Extended’s PrimitiveBatch or filling solid polygons and circles, nothing too major.

All the text is currently using Monogame’s SpriteFont. I’m not familiar with alternatives but the bulk of the text drawing is funneled through these 80 or so lines of code: MGUI/DrawTransaction.cs at master · Videogamers0/MGUI · GitHub , and these 40-ish lines MGUI/MGTextBlock.cs at master · Videogamers0/MGUI · GitHub . And there’s a simple little interface used in this class for handling things like the text wrapping: MGUI/MGTextLine.cs at master · Videogamers0/MGUI · GitHub . So nothing too major to refactor if you had some better text drawing in mind.

1 Like

J’ai été feuilleter ton repo de UI MonoGame et j’ai adoré !!! Très bien fait !!! Un gros merci de partager ta librairie !!!

PS: Entre Saguenéen on doit bien s’encourager :wink:

1 Like

Merci! :grin:

T’es dans le Discord du Saguenay? Sinon je peux t’inviter.

1 Like

S’il vous plait, ça serait apprécié, Merci :stuck_out_tongue: Tu peux me trouver dans celui officiel de Monogame sous @BlinkSun avec le même avatar qu’ici :wink:

1 Like