[1] https://github.com/ahyatt/llm-buddy

Tangent: SRE was very color-heavy and that led to some long ANSI sequences. From the recently decompiled source [1] you can see that I tried to pick shorter ANSI sequences when I could. In particular, going from color 0x0* to 0x1* we could save 1 byte, and going back to the default white on black we could save between 1 and 4 bytes. But if you're bandwidth limited there's also an option to turn off color entirely.

[1] https://github.com/joeshaw/sre-reconstructed/blob/main/src/s...

Uber and Ubuntu are not in my word list (which attempts to exclude proper nouns), but maybe I should add uber, uberant, uberous, uberously, uberousness, uberty, uberties.

I had a self-imposed time limit of 1 day for this side quest, but there are lots of ideas in the comments here so someday I may come back to this project and give it another day.

You have vector s in blue, and then vector u in teal, and then vector v in orange.

In the diagram, it's "Subject", "First Reflector", "Second Reflector". I think it'd be better if these labels were "Subject s", "First Reflector u", "Second Reflector v" so that we can match up the text to the diagram even without color.

Later you have "The pair of vector u and v is called a rotor". But these colors do not match the earlier colors, and it makes it hard to connect to the diagram.

In the 3D diagram, I think it would be better if you used the same color scheme as for the 2D diagram. Same for the circular reflection diagram.

Suggested colors:

- subject s - orange in every diagram (currently blue, blue, blue)

- first reflector - teal in every diagram (currently teal, magenta, pink)

- second reflector - blue in every diagram (currently orange, teal, orange)

This makes the rotor colors more similar to each other than to the subject.

Changing the graph is another optimization that's commonly used. A graph of rooms is far smaller than a graph of tiles, and you can precompute paths on the small graph. The landmark heuristic can work on that graph too, although with the small examples on the page you probably wouldn't need to.

1. If the cost of a tile decreases, the precalculated heuristic will be too high, so A* might find a non-shortest but ok path. In game, you can think of the dorf as following the path they already know about, because they don't yet know that there's a shorter way.

2. If the cost of a tile increases, the precalculated heuristic will be too low, so A* will find the optimal path but it will take a little bit longer (still not as long as if we weren't using this heuristic). In game, you can think of the dorf as following the path they already know about, but running into a wall, so then they find a path around it.

However, MSDF can handle lots of distance-based effects (glow, shadow, outline, gradient, etc.)[1], and I don't think Slug does that. And MSDF is constant time whereas (I think) Slug is going to vary depending on the complexity of the font.

The Slug paper [2] says:

  All of the techniques that store data in a texture atlas are inherently using a discrete
  sampling of what is actually an infinitely precise description of a glyph outline. This
  inescapably leads to limitations that can be mitigated by increasing the resolution of
  the texture atlas, but that can never be completely removed. For applications that
  need to render a wide range of characters at potentially large font sizes, a texture atlas
  capable of producing glyphs at an acceptable level of quality may have prohibitively
  large storage requirements.

[2] https://jcgt.org/published/0006/02/02/

[1] https://en.wikipedia.org/wiki/Theme_Park_(video_game)

There's a different blog series that does go into plate tectonics: https://frozenfractal.com/blog/2023/11/13/around-the-world-2...

Coincidentally Civ 7 just announced they're using plates with voronoi for their new map generator.