apostolique / apos.gui

UI library for MonoGame.

Notable projects

Gamedev

• Apos.Gui - UI library for MonoGame.
• Apos.Input - Polling input library for MonoGame.
• Apos.Shapes - Shape rendering in MonoGame.
• Apos.Tweens - Tweening library for MonoGame.
• Apos.Camera - Camera library for MonoGame.
• Apos.Framework - C# Templates that I use for new MonoGame projects.
• AposGameStarter - MonoGame project starter. Common files to help create a game faster.

Research

• Texo - Music composition software.
• BinaryInput - Proof of concept for writing text on limited devices.
• Vyne language - Vyne programming language.

Games

• AposChess - A chess variant that might or might not be fun.
• Justin Time - Made for the Ludum Dare 47.
• ProjectCore - Made during a MonoGame jam.
• Looking for Group - Made for the Ludum Dare 46.

Other

• Mitten - Infinite canvas drawing application.
• apos-docs - Documentation static site generator.
• MotivationTracker - Simple application to track days working on something.

Socials

• Discord
• GitHub
• Personal Site
• SoundCloud
• Twitch
• Twitter
• YouTube

apos.gui's Issues

Lifecycle rework

Currently, a component's lifecycle looks like this:

Init:

• Constructor

Update:

• UpdatePrefSize
• UpdateSetup
• UpdateInput
• Update
• Draw

One issue is that layouts are done in UpdatePrefSize and UpdateSetup. If something invalidates the layout in a later step, it breaks the Draw and can introduce flickers. The current solution is to delay the changes until the next frame using something like IMGUI.QueueNextTick or similar mechanisms.

I think it could be possible to reorder the lifecycle steps so that the layout is done at the end:

Init:

• Constructor

Update:

• UpdateInput
• Update
• UpdateLayout
• Draw

UpdateSetup would be renamed to UpdateLayout. UpdatePrefSize could be done in Update to simplify.

An issue to consider is what happens with UpdateInput since inputs would be done on the layout from the previous frame? I think this is ok since you're interacting with the visuals from the previous frame anyway. Actions can have instant feedback unlike what we have now.

From a game's point of view, this is the update life cycle:

Game1.Update() {
   IMGUI.UpdateSetup(); // UpdateInput, Update

   // ...

   IMGUI.UpdateCleanup() // UpdateLayout
}

DirectoryNotFoundException

Hello,

This looks like a really good library. Unfortunately, I cannot seem to get it to load my ttf font file. This is a problem on my end, I'm just not sure how to resolve it...

GuiHelper.Font = DynamicSpriteFont.FromTtf(File.ReadAllBytes(Content.RootDirectory + "/Assets/Fonts/Capsuula.ttf"), 30);

When it tries to read the file it throws

File structure:

Pipeline:

Any thoughts?

Wrong GamePad Key in Defaults for MoveRight, MoveUp and Move Down

Hi,

I noticed that there are typos in the Default.cs file:

Currently, the MoveRight, moveUp and MoveDown all use GamePadButton.Left

        public static ICondition MoveRight { get; set; } =
            new AnyCondition(
                new Track.KeyboardCondition(Keys.Right),
                new Track.GamePadCondition(GamePadButton.Left, 0)
            );
        public static ICondition MoveUp { get; set; } =
            new AnyCondition(
                new Track.KeyboardCondition(Keys.Up),
                new Track.GamePadCondition(GamePadButton.Left, 0)
            );
        public static ICondition MoveDown { get; set; } =
            new AnyCondition(
                new Track.KeyboardCondition(Keys.Down),
                new Track.GamePadCondition(GamePadButton.Left, 0)
            );

Because of this, the sliders do not work correctly (possibly text boxes too).

Rethink the way inputs are consumed

Right now, components have an update input step that returns a bool to indicate whether the component has used input. This is useful to block other components from also consuming inputs. In practice, I found that this isn't good enough.

In reality what we want is to mark specific inputs as consumed. If two components do something on spacebar, you only want one of them to be allowed to use spacebar. But it's fine for a third component to do something on another key like enter or arrow keys.

This should not be confused with focus handling. Focus just gives a specific component the first pick on inputs.

Rendering pipeline rework

The current way of rendering components isn't all that efficient. The scissor rect handling requires flushing the batch between each components. We're using the SpriteBatch which doesn't support drawing shapes natively without hacks. Font rendering is done with FontStashSharp, it would be nicer to use MSDF for example MonoGame.MSDF-Font-Library.

In the long term, it would be nice to support fancy effects for example check the UI in Frostpunk. It's possible to do something like that already but it would be really painful.

Some features to think about:

• CPU cropping directly on the vertices. (Avoids needing scissor rects.)
• MSDF font
• Shapes, maybe with a simplified version of Apos.Shapes.
• Masking

Ideally you can have cleaner batches.

UI overlap

Find a way to extend the API to provide support for components such as dropdowns, or even tooltips.

Resolution change

Hi,

I was wondering what the intended way to change resolution is right now? I found an old issue about this topic, but it seems a bit dated: #1
could you give me a small example how to use PushScissor()?

Thanks a lot! :)

Rethink the UpdateSetup step

I'm finding that the update setup isn't adequate in some situations.

Currently, the update setup works in a top down way. Parents give position and sizes to their children, then they let their children do the same to their own children, and down it goes. Parents take decisions based on their children's preferred sizes. This is how it's done in a managed UI.

It is also possible to create a UI in an unmanaged way. In that case, it's up to the components to manage themselves. (The first parent element in a managed UI is usually unmanaged.)

A problem right now is that in order for a parent to take good decisions, it's children need to be aware of the size that they want to be. The update setup current works in a top down way. The problem becomes obvious if you consider nested panels. The top panel might ask a child panel's preferred size, but that panel might not yet know until it also runs it's own update setup.

Instead, a new function could be added to the API. It would get called before update setup and it would work from the bottom up. This would let the bottom components figure out which sizes that they want, then their parents can use that info to also figure out their own preferred size. When all the preferred sizes have been figured out, then you call update setup. This would make the algorithm start from the bottom up, then back down the other way.

You can think of this new function as separating the layout's dream world from the layout's practical world. In the dream world, things can be any size. You go up the chain, all the components are happy, then you reach the top component for example a screen panel. A screen panel starts to introduce limitations for example, nothing can exist outside the screen. Then we go back down and fix all the components.

All of this might sound complicated, but it's really not and it makes it much easier to reason about each component's place in the UI world. The main problem with that is to figure out how to not add too much overhead. Are we now doing twice the work?

Support scaling to deal with different screen sizes

Global scaling for the UI would be fine, per widget scaling may be interesting too.
Different filters may be necessary perhaps (ie nearest for pixel fonts, etc.)