[Tool] FairyGui - Ui Library/Editor for monogame

Are you still worrying about not having a visual editor, or using IOS without the right tools to generate the interface for you? Let’s try our ui editor. My editor name is fairygui-editor. I am adapting it to monogame. In fact, he is running fine, but there are some minor issues that need to be fixed. You are willing to help me. Test it? I believe I can give you a good experience.

Please give us a star~

Official website: http://en.fairygui.com/
project address: https://github.com/fairygui/FairyGUI-monogame
Show results:

I am restricted from posting more styles, you can download the project yourself to view


Hi Man,

I grabbed a copy of the demo and it worked first time. Only bug I saw was in one of the demos drag and drop wasn’t working.

That is very minor though.

Best GUI I have looked at so far so I give you a virtual hi-five for that.

Had a quick look at the gui editor, and it probably a little heavy weight for my needs. I always use a single gui style sheet for all gui assets and do partial scaling at run time. (So a frame is made up of corners, edges, and fill and you glue them together to display a frame of any size.)

Your editor scales images to the desired size, which basically means you need an image for all elements if you don’t want scaling artifacts.

But apart from that, very nice.

Thanks, this is my first day to support monogame, maybe there are many places that are not satisfactory, but I will fix it.

This is our editor, our editor has more features than you might think.
The language on the interface will change from country to country, so you don’t have to worry about not reading the screenshots.

Let me be clear, there is nothing wrong with your system (apart from a minor bug).

It’s just the basic design assumes you are going to create assets for each and every gui element.

That’s fine if that’s what you want to do.

For me it is not though. I want my gui to automatically scale to the users display settings without scaling artifacts.
For this, you have to take a modular approach and create display elements from small assets which only depict parts of the final element (corners, edges, etc.)

To see what I mean, take a screen shot of one of your demos, then in an image editor double the size of it. You will see scaling artifacts, and it is those I try to avoid.

On the whole I am very impressed with what you have done.

FairyGUI provides a UI adaptation strategy that automatically adapts to the resolution of various devices for game development, which means that developers only need to create a set of UIs to adapt to all resolution devices.

Usually we choose a fixed resolution for UI design and production. This resolution is called design resolution. For example, 1136×640 and 1280×720 are relatively common design resolutions. When a design resolution is selected, the size of the largest UI interface (usually the full screen interface) is limited to this resolution.
The resolution of the running device is called the device resolution. This resolution is not necessarily the same as the design resolution. You need to project the UI interface to the screen with a certain zoom.

When the design resolution and device resolution are inconsistent, the first thing to do is global scaling. This global zoom is transparent to the inside of the UI, which means that all UI interfaces don’t need to worry about the existence of this zoom. For example, if the overall size is doubled and the size of a window is 400×400 pixels, the window size that will eventually be displayed to the screen will be 800×800 pixels, but if you read the width and height of this window, it will still return 400×400. , all internal coordinates will not change.

The screen size after global scaling is the logical screen size. In the above example, the device resolution is 1280×720, and the global scaling factor is 1.125, then the logical screen size is (1280/1.125=1138, 720/1.125=640)= 1138x640 . The size of the GRoot UI root component always fills the logical screen, that is, the size of the logical screen can be obtained by GRoot.inst.width and GRoot.inst.height.

After global scaling, most UIs don’t need to be adjusted. With one exception, they are designed to be full-screen. In the above example, at the design resolution, the size of the full-screen interface is 960x640, and we also design full-screen components by this size. After global scaling, the size of the logical screen becomes 1138x640, and the size is inconsistent. At this point we need to resize the component to make it full.

In general, the screen size will not change after entering the game. But if you are developing a desktop game, or a game that supports horizontal and vertical screen switching, that is, the screen size will change, then the full screen interface also needs to add constraints on the screen size.

Of course, this is just one way to handle a full screen interface. In some cases, such as the “MatchHeight” mode, which is a high-priority adaptation method, this method ensures that the vertical direction of the UI interface is always full, and the horizontal direction may exceed the screen. This kind of adaptation requires the designer to have a “safe area” design thinking, and can’t arrange content beyond the screen. For example, center the full screen interface and sacrifice content on both sides.

In this way, the left and right edges will be cropped off by the edge of the screen, which requires the designer to take this into account when designing.

The full-screen component needs to be reset to full screen during the adaptation process, and the component size will change. In this case, the associated system needs to be used to automatically lay out the elements in the component in the correct position.

I hope that my strategies can help you.

Hi man,
You are missing my point.

Take a single gui element, a button.
With your system this is a set of bitmaps the same size, one for each button state.

When the entire gui has to be scaled, then the button will be scaled.

That is fine, it’s just HOW it is scaled that I have a problem with.

Simply taking the bitmap for the button which is for example 128 by 64 and calculating it needs to be displayed as 256 by 128 then drawing that bitmap with the new size introduces visual scaling artifacts.

Now that could be absolutely fine for you application. You may not care about that at all. I do though.

So MY button would actually be a set of parts top left corner, top edge, top right corner etc.

When I need to scale the button I would draw the top left corner at it’s original resolution. Then draw the top edge only scaled in X, then draw the top right corner at it’s original resolution.

This minimises the visual scaling artifacts. Why is this important to me. Well consider a rectangle with a 4 pixel wide border. When you scale this in your system the border gets scaled as well. So you end up with a border N pixels wide.

Again this might be absolutely fine for your needs. I just hate it. I have had to write code that worked on many, many resolutions without re-coding. At first I just did things like render to an off screen buffer at a fixed size then render that buffer as a full screen quad. Looked awful. Blurry and horrible.

Then I tried keeping the GUI fixed size and rendering it to parts of the of the final screen. That looked great but was unuseable on hires screens. You couldn’t read the text.

So the only solution I have found that always works is the approach I mentioned above. It does require the use of signed distance field fonts as the text has to scale by the same scale factor as the whole display, but it works.

If you are working against a fixed resolution, it’s totally pointless and creates unneeded overheads, but if you work in a variable resolution environment. It is the best solution I have found.

I would love someone to come up with a better one though.

Hi @LCEngine, lib looks cool, haven’t personally tried it yet though. It’s free for commercial right?

Anyway just to add to what @StainlessTobii said, you can take a look at how Unity explains it:


This page summarize the problem perfectly and suggest a way to solve it. :slight_smile:

Yes, it is free. @GeonBit @StainlessTobii

Sorry, I only reacted now.

I think what you are talking about is this thing.My editor has already supported it.

It is enlarged by a 9-slicing method from a smaller picture to such a large size.This set of unity support we also perfectly support it in the editor.

That’s cool. I didn’t find that in the editor.

Will have another look when I have time.

This looks really nice!

Is there transform / rotation support on the widgets? (ie. position text at a 45 degree tilt)

Edit: found it, with pivot too. Awesome.

If you like our library, please order a star for us.

Ok, it’s been a few days, I don’t know how many people are using us? Our library is very complete, I don’t know why people are not willing to use it? Can you tell us let me know where to do it and improve the library? We have a FairyGui.Test that shows most of the usage and has full documentation. It can be said that we have implemented all the libraries that most people need. We are not a brand new project. In fact, we have been running well for many years and have many commercial games. I hope that you can use it and give feedback to us.

The picture shown above is just the tip of our iceberg. We have dozens of cases that show different effects.

I’m porting your Vision version to another engine (was originally using the cocos version, but the Vision one had less cocos stuff intermixed) - actually got 90% of that done in a few hours, just the render/input specifics and ditching some of the cocos-libs stuff to go (which is still a fairly large chunk of work). Though I’m tempted to embed Mono there just use your MonoGameAPI almost as is.

It is by the far the best UI library I’ve come across, very feature complete.

I am very happy to hear from you, we have very good support for a lot of engines.

Including cocos, I hope this will help you.

I’m not happy because it does not support Linux OS