Mikko Mononen

https://mastodon.gamedev.place/@MikkoMononen

Coder and woodworker. Author of Recast&Detour and NanoVG. Previously at Epic Games, Unity, Tinkercad, Crytek, demoscene.

https://github.com/memononen

Public Key

npub1rx7lucvjc2j68wgd3s08wypffet2w0zfksuqm74kvtr9gcxks56s45v92v

NIP-05 Address

mikkomononen_at_mastodon.gamedev.place@momostr.pink

Profile Code

nprofile1qqspn007vxfv9fdrhyxcc8nhzq55u44883ymgwqdl2mx93j5vrtg2dgpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsasn4nz

Publishing to

nostr.mom

relay.damus.io

nos.lol

Author Public Key

npub1rx7lucvjc2j68wgd3s08wypffet2w0zfksuqm74kvtr9gcxks56s45v92v

Show more details

Last Notes

2026-03-02 13:31:24 UTC

- reply

Bulk edit is interesting thing too. In UE we used DataTables a lot, which is a like CVS which can have engine types too. The table view works for that sort of data really well.
You could batch edit things using a grid too, but UE had bad design choice where the widget customization was per row (label + value), which made reusing the custom edit widgets impossible.
I think this is interesting direction, but not there yet :)

2026-03-02 13:29:01 UTC

- reply

I dont have a good answer to the docking yet, but in UE you could customize (and recall) the layout per asset type/window (IIRC), which is one option.

2026-03-02 13:27:02 UTC

- reply

That sounds similar to the UI I was trying to build too. I think the lesson to learn from web is that there is a low level UI layer, and you can also make the common widget logic into shareable libraries.

2026-03-01 14:29:12 UTC

- reply

I think what I'd like to have is a way to edit many (smal-ish) files, which may have different types of editors (hierarchies, graphs, tables, timelines).
Have the UI reflect: files > asset > data more clearly than many of the editors do today. There should be a way to work with many files side by side.
Finally, share common editor parts (outliner, details). I have less preference whether those would be fixed side panels or some holistic dockable mess.

2026-03-01 14:23:59 UTC

- reply

I think option 4 could be, each document having their own outliner and details panel. And you could have multiple documents as tabs or separate windows. Kinda like web browser.
I think that is close to how UE works, but it does it in more haphazard way.

2026-03-01 14:14:46 UTC

- reply

UI is half the story, so I have have been working on that too. Initially I wanted to try some more esoteric UI ideas, and worked on my own UI lib too, but it turned out to be too big distraction, so I ported my stuff over dear imgui.

2026-03-01 14:13:02 UTC

- reply

I'm working on my grand unified game data theory :) I dont know what the output will be, but currently it is shaping up to be a library which handles hierarchical data, data inheritance, property binding, undo/redo, etc.

2026-02-28 18:56:01 UTC

@npub1up3…qyrr I'm trying to figure out how to organize multi document editor with shared panels (like details, outliner).
I remember you had some thoughts on that for you editor. Is there something you could share about your design?
My main concern is how to make the whole thing understandable.
For example, I think the Unity's solution feels messy (easy to miss how things connect).
GDevelop has files as very top level thing, and the whole editor changes based on that. Which seems limiting.

2025-10-30 18:13:06 UTC

- reply

How do you create the business logic with that? Say assign value = 20 in that button lambda?
My template-fu fails me on this case :)
Also wondering, how does that compare to, say, if the definition was just a lambda that called those widgets? You did mention that you can actually build the tree with the builder.
Not to critique, but very curious where this is going.

2025-10-29 10:58:22 UTC

- reply

I like that approach too, it's very versatile.
Even if we had different motivations, I think that separating the widget declaration and logic (relatively locally) is a good idea. it helps to keep the code cleaner. Especially once you start adding conditional styling and what not, it starts to get hard to see the logic from the structure.

2025-10-28 21:29:43 UTC

- reply

I did something similar-ish a while back, but in C.
https://bsky.app/profile/mikkomononen.bsky.social/post/3ldrldirbz52r
(there are few more post around that time)
I wanted to find a way to do 1 pass imgui with flex box like layouting. I ended up defining small parts of the UI in stack, layout, and then call the logic.
I really liked the separation of layout and logic (even if it was hard to find the name for the logic function).
The 1 pass does limit nested reuse, but that was just my obsession :)

2025-06-20 11:57:26 UTC

- reply

it kinda wants linger on your tong, doesnt it ;)

2025-06-10 21:04:04 UTC

I have been researching and working on a text stack good part of this spring.
It is called Skribidi, and it can do bidirectional text layout, rendering and editing.
It has fairly lean dependencies and is MIT licensed.
https://github.com/memononen/Skribidi
It kinda started as a self help project trying to deal with weltschmerz and burnout. I needed something the felt even mildly meaningful and complex enough that I could hyper focus on details.
Any feedback welcome!

2025-03-15 10:41:07 UTC

- reply

Ok, so it sounds like what I'm going towards too.
I have some random ideas to for things that change often, like numbers, but I will save those after I have done some testing. E.g. you could mark a text to have just numbers, in which case it would use the old skool simple layout and no shape caching (apart from the stuff that goes to atlas). Not sure if it's worth it, though.

2025-03-15 09:24:46 UTC

- reply

I'm currently trying to figure out the details of word wrapping and multi-line caret positioning. So many odd cases to deal with :D

2025-03-15 09:24:01 UTC

- reply

re: atlas word caching, Text hates you (
https://faultlore.com/blah/text-hates-you/ ) popped on my timeline yesterday, and it mentions caching words so that you dont get transparency issues with overlapping glyphs. Another reason could be sub pixel positions.
Just thinking out loud why you would want to do it... I'm currently not planning to do it.

2025-03-15 09:22:03 UTC

- reply

So when you do DoButton("Foo"), do you also cache the shaped text (positions), or just the glyph bitmaps? I'm not yet at the perf issues, but the text layout is a lot of work.
Sorry for the odd questions, I noticed that since I'm working on similar stuff, I read many of your posts assuming that your "caching" or what ever, is the same as I'm working on, but it always is not :D

2025-03-14 17:29:53 UTC

- reply

"letter" sounds like glyph cluster (which is not grapheme cluster :)).
is your ui retained or im? I was thinking of making im like api, and would like to cache the shaping result too (the glyph positions).
It should be possible to shape per word, but then you need to do some of the bidi stuff manually.

2025-03-14 16:27:23 UTC

- reply

What's your caching strategy? I've seen caching the whole shaping result, some seem to cache words (too).

2025-03-04 09:33:58 UTC

- reply

Thanks!
There's a quit a few good libraries that do things half way (harfbuzz, sheenbidi, libreqm), but even so there's a ton of things to figure out for the final stretch.
Also, there are some really cool Rust projects on the topic (like https://github.com/pop-os/cosmic-text), but not the kind of dependency I'd like to drag in for a C project.

2025-03-04 09:00:48 UTC

- reply

(Sorry to hijack this post, dunno how this tooter thing works :)
You had bunch of posts earlier about bidi text. What did you end up using? I'd like to get simple wrapped text + text edit figured out, but not invest too much into it.

2025-01-31 14:21:34 UTC

- reply

I had a second look at your video, and I made so many assumptions! :) I guess I'm so hard wired to think that all the documents would go in the place where you have the settings/game/scene stuff.
I like the idea that you have "editor" level tabs, and the tool windows inside them. In UE the arrangement of those tool windows was per editor not doc (make sense or else you end up micromanaging windows). Asset browser is always a bit of a weirdo.

2025-01-31 11:59:48 UTC

- reply

Some docking systems (e.g. https://github.com/Dirkster99/AvalonDock) have separation of documents and tools. Not sure about all the constraints, but at least they do not allow mixing tab wells for tools and docs.
I'm sure it extra fun if you have a common "inspector" and then you switch between documents or have multiple in view at the same time. E.g. each window can have their own selection which affects the inspector.