Short blog post I had on substack, which I'm retiring and posting an update on here. The technique I'm describing avoids using a 2D texture and stores the built glyph directly in bytes.

As you can imagine this is pretty bad in comparison to the 2D texture approach. Storing glyphs in 2D Textures has benefits like tightly packing, overriding sections of a texture and most importantly the fragment shader can most likely read faster from a texture than reinterpreting from our storage buffer.

With that said let's just see if we can get this "alternative" working :)

Initialization & Building

I’m using Odin for the code examples and the wonderful stb truetype library for loading and dealing with fonts.

Let’s look into a simple way to implement this when looking at the data.

// mapping codepoint + pixel_size to the built glyph in the glyph buffer
Glyph_Key :: struct {
	codepoint: rune, 
	pixel_size: f32,
}

// glyph information 
Glyph_Slot :: struct {
	

Applications store data

Sublime Text loads all files, buffers, layout, and other data back from the last time you quit. This allows you to quickly jump into action. I'd like Todool's save format to be just as good.

Here's how my first file format looked like:

• data: stored general info about the editor
• tree: stored task related info like indentation, time info, string content, special content in ^1.123123123.1^ which wasnt in the example image

Let's keep it short

• Pros
  • quick & easy to start with
  • manually editable to add new features
  • loose structure
  • raw text viewable
• Cons
  • users could modify the data, potentially deleting data
  • hard to change: manually edit, scrap your save file or go the old read -> new write -> new read route
  • hard to read: odin does help since it has a basic [scanner](https://github.com/odin-lang/Odin/blob/master/core/text/scanner/scanner.odi

Hey everyone, i have 2 weeks of vacation so i plan to work more on Todool these weeks.

I opened a Discord if anyone is interested on following Development more closely there.

The design decision of sticking to Trees + different Sub Node Types holds up really nicely. Through that the editor starts to feel really solid. So thinking about the design of the project you're making is something I'd really suggest, otherwhise you'll end up like me abondoning ideas completly and having to start over. That's why the project has gone on for so long.

I implemented multiple Views (only vertical) as well, in which you can open trees independently and focus on them. The search mechanism was recently in a Tree too, which i thought was clever but didnt quite work out. So instead I pulled that out into its own mechanism + keymapping. Same thing with the (Date) Time Tree, which presented uneditable data in a tree. The idea was that you could open tha

Todool's old structure relied on Task and Text Nodes alone.

TaskNode :: struct {
    prev, next: ^TaskNode,
    parent: ^TaskNode,
    
    task_head, task_tail, task_jump: ^TaskNode,
    text_head, text_tail: ^TextNode,
    
    ...
}

TextNode :: struct {
    parent: ^TaskNode,
    prev, next: ^TextNode,
    
    length: u8,
    bytes: byte,
}

task_head, task_tail, task_jump: ^TaskNode,
text_head, text_tail: ^TextNode,

...

}

TextNode :: struct { parent: ^TaskNode, prev, next: ^TextNode,

length: u8,
bytes: [BOX_CAP]byte,

}[/code]

This was obviously bad. It seriously limited the more advanced things i wanted to do. I wanted TextNode's to be more generic. Since i got really frustrated i began thinking about another issue i didnt like about Todool, the UI.

I had built a Retained Mode UI (RMGUI) around the tree data and a completly seperate Immediate Mode UI (IMGUI) for the sidebar, menu, notifications, etc. This was terrible since i had 2 different systems all working in a different way and not playing well together.

So i started experimenting with RMGUI again, since i really liked how powerful they can b

Welcome to Todool

I've been working on this project since August 2019 in my free time. I started prototyping with Raylib, afterwards I wanted to go more lower level and started implementing rxi's cached software renderer. Took a bit of time but at the end I'm happy with it.

Remember I work on this project alone, so progress is slow. You can follow my progress on Twitter, I will use the blogs here to show more of the technical / code aspects.

Suggestions are welcome on the forum or general discussion.

This week i worked on implementing networking for collaboration in the editor. I want it to be kind of live, i.e. Google Docs. It's coming along slowly, still goes out of sync a few times. My idea is to sync all users to the host file, simulate key / mouse input across the network.

[youtube]https://www.youtube.com/watch?v=7nWRRRO