@craftworkgames @1stAnd10 I actually have started hacking into the MonoGame.Extended.UI a while ago. I’d say sure making GUI library is hard, which I believe you agree with me 
.
I think I’m going to write a quick guide and a summary of my findings in the Extended category. Once we have a common ground then we can convince more people to contribute, or at least have an agreement on the direction the library would take.
Looking forward to seeing what you come up with.
Only want to throw in my unfinished approach of recreating the legacy Unity3D GUI for MonoGame
I know this is an old post but I wanted to shout out Empty Keys. Give yourself some time to learn WPF and you won’t regret it. Hands down my favorite UI.
I have started my own UI Framework, the code can be found on GitHub: https://github.com/Apostolique/AposGui
Information about my design choices are in the wiki: https://github.com/Apostolique/AposGui/wiki/GUI-design-choices
Right now, I support mouse, keyboard, gamepad.
Empty Keys UI 3.1 is out - https://www.nuget.org/packages/EmptyKeysUI_MonoGame/
Nice I will try it
What happened to the first Empty Keys video on your YouTube channel? It’s currently set to private and I assume that’s the “Hello World” intro tutorial. I’m trying to figure out how to use Empty Keys and I can’t any other basic instructions.
It was bit obsolete, but you can find simple example on GitHub https://github.com/EmptyKeys/UI_Examples/tree/master/Empty_Example
Yeah, that’s how I’m trying to work out how to use it. If I get stuck I’ll come back here.
Id rather see a ui library as a addable project in pure c# / monogame.
But i like most of them about as much as i liked my old one.
I actually keep rewriting one i have been working on and off , of for a long time.
But i keep throwing it out and starting over.
It is the curse of a games programmer.
You think you need a new GUI, so you spend a couple of days looking around at what is available, decide none of them are quite right, and start writing your own … again…
I have been writing games for 40 years, and I have probably wrote at least 50 GUI’s
My UI library is designed as a core to build your own UI on top. Perhaps you won’t need to build so many UIs anymore.
I can answer questions if you are suspicious.
In my game, I created this fancy Integer input box built on Apos.Gui: https://gfycat.com/ultimatecomfortablefurseal
I can use backspace and delete to remove characters in front or behind the cursor. I can write integers with any keyboard input layouts. I can use the scrollwheel on my mouse along with up and down arrows on my keyboard to increase or decrease the numbers. I can also use my mouse to move the cursor: https://gfycat.com/smoggycomplexblackrussianterrier
That’s just an example of a custom component.
I know this feeling well 
The GUI system in MonoGame.Extended is probably in it’s 3rd iteration and to be honest we’re still not happy with it. I’ve already got plenty of ideas for the next version.
I probably made a least a dozen GUI’s before I even started working on the one in MonoGame.Extended. Writing a really good GUI system is just… hard.
Hi,
I see there are many third party options available.
In the past, I’ve used TomShame neoforce controls and the functionality and look was sufficient for me.
However it seems to do a lot of memory allocation on the heap which leads to garbage collections and potentially frame drops. Also, as I have used it it does not seem to be resolution independent so it looks really bad on 4K.
I need a simple textbox without copy paste, multiline, selection… But still proper input and resolution independent drawing.
Any of the suggested UI librairies offer a simple textbox with no heap allocation on every frame ? I don’t care if there is heap allocation on initialization, keypress, activate etc so long as it doesn’t happen every frame when the user is not interacting with the textbox.
Otherwise, I’m considering just digging into TomShane NeoForce and see if I can get rid of the allocations.
Well, not sure about the Allocation behavior of this one, but I’ve just started using it and really like it.
You ****ing bet it is, but I think my project is reaching a pretty good point where I don’t regret anything about the way it’s being done.
About staying in the dark about this, I think the best way to maintain a solid pace is to not rely on public opinions for your endorphins and emotional venting about your daily progress, because hype dies and it will take you and your project with it at that point.
I work on it just about nightly. On the fun challenges of making a UI, it’s mostly nesting Widgets in other Widgets, differentiating what should be in the abstract widget class or the inherited Buttons and Layouts, minimum and maximum sizes, all objects designed to be serializable and initialized in about 4 different ways, finding ways for the parents and children to carefully communicate with each other without causing infinite loops… I’m glad I’m mostly done with things like that and am on to the fun parts like visual effects, and thankfully I designed it in a way that’s based off Microsoft’s Forms system, where EventHandlers are used heavily and Events can effectively do anything to the base Widget.
The aim of this project is not only to be a good UI library for MonoGame, but to be a framework that competes with Qt and Windows Forms, because frankly those alternatives have aged like fine cheese in my honest opinion. A UI framework should be designed with any spacial animation in mind from the beginning, it cannot be easily added later.
Things like light diffraction, lighting, and opaque windows are planned. Would also love to take advantage of the new MonoGame browser support to have people using this making websites.
With that, I will probably find a way to monetize it at some point, possibly through commercial licenses, possibly through Patreon? Idk.
Be warned that it’s not in a usable state at the moment. Well, you could use it, like you could use a half finished toaster.
Huh, writing shaders is easier than I thought it would be. The only challenge came in just the week of learning HLSL, which is ancient and very wonky. Crazy how a little 100 lines of shading code can make something look polished immediately.
I’m glad you brought up allocation, that reminds me that I’ve got some very bad offending every-cycle methods that add garbage to the heap and classes that need to be structs.
Damnit I just wanted a textbox and now I’m knee deep into a menu redesign… I love GeonBit.UI and the default theme actually meshes really well with my game. I didn’t get the time to test the allocation but a quick glance at the code looked like work is done to use structs when testing for input and looked all good from a cursory glance…
Also, I think I figured I was a bit dumb with my use of TomShane controls… I could have simply omitted the calls that are required on each Update / Draw when my gamestate knows no textbox is currently visible, which would have been good enough for my scenario…
