This Subaru had a very severe accident this morning in Boulder, CO. I'm not going to dwell on specifics. But it likely was airborne for 100+ feet and landed on other (unoccupied) parked cars. Look at how protected the driver space is (it is believed the door was removed by jaws of life). Driver was reported to be extracted alive, no further info available currently.

In late March, 2026, Eric Lengyel made his amazing Slug technique completely patent-unencumbered ( https://terathon.com/blog/decade-slug.html ). As a long-time graphics programmers and open source contributors, particularly with projects like OpenSceneGraph/VulkanSceneGraph, it didn't take us long to get some basic "proof-of-concept" demos going and start exploring the Slug algorithm in-and-out.

Over the last 2.5 months, what *started* as a research experiment "on the side" has evolved into something we're actually quite proud of! And while the project is still in its early phases, we've decided it's matured to the level where we're finally ready to start "putting it out there" and soliciting feedback. We're calling the project `Slughorn`; a name we chose to try and capture our goal of a single OSS library solution for "shoe-horning Slug" into other visualization contexts (OpenGL, Vulkan, DirectX, etc).

Slughorn is MIT-licensed open source and available for commercial use without paying anything. It is written in and requires C++ 20, and has no third-party dependencies and builds via CMake. It has been tested on Windows and Linux but should also be compatible with MacOS and embedded/mobile platforms that support GPU APIs. 

Since a picture is worth 1024 words, our Github page with lots of pictures and even videos is here: https://github.com/AlphaPixel/SlugHorn/

The official project website is at https://slughorn.io/ and it links to the GitHub and has the User Guide and Python and C++ examples.

You'll also find links to our (WIP) `UserGuide`, as well as a `WhatsNext` document ( https://slughorn.io/WhatsNext.pdf ) listing some of the places we want to take `slughorn` in the future.

Current Supported Backends

FreeType

NanoSVG (paths & gradients)

Skia (paths only, stroke-to-path)

Cairo (paths only)

Blend2D (paths only, stroke-to-path)

Optional dependencies for extra capability:

NanoSVG: optional, is a SUBMODULE

MSDF: optional, also submodule

pybind11: same as above

serialization/glTF support: same as above

Cairo/Blend2D/Skia import is also optional, but NOT submoduled

If you're just interested in the "highlights":

- We honestly believe we're onto something special here. While we aren't necessarily *inventing* anything new (thank you again, Eric!), what we **are** doing is applying Slug, which was originally intended just for text, in new and interesting ways. Glyphs are, after all, just a "kind" of vector graphic; why can't it apply to **all** vector graphics!? There are no "bad ideas", right? :)

- `slughorn` itself isn't a "rendering library"; its purpose is to serve as a single input source/adapter for other systems to use for rendering. We have a *very* complete FreeType2 backed capable of processing all COLRv0/1 emojis, as well as a native Canvas API--inspired by the HTML Canvas--for authoring content programmatically.

- SVG content is handled via NanoSVG, and we have excellent support for importing paths, transformations, and even gradients. Strokes and text are *possible*, we simply haven't had the **time** and resources to do it.

- There is rudimentary support for converting Blend2D/Cairo/Skia content into slughorn data. Like NanoSVG, these can (and eventually will) be expanded to support additional features (gradients, stroked content, text, mask, patterns, etc), but we're waiting until the core pieces of `slughorn` stabilize before committing *too much* to these.

- We have a **lot** of experience writing Python bindings, and slughorn comes with complete pybind coverage. In fact, Python is the primary environment for all of the CLI tools (the Atlas inspector, font "packer", GLSL emulator, etc).

- `slughorn` content can use `msdfgen-core` to generate "sidecar" data alongside its own native format. We currently use this channel for creating masks and different kinds of visual effects; in the future, we plan to have a lot more capabilities surrounding this.

- OpenSceneGraph has been our rapid "testbed" because, well, we’re really, really comfortable with it! :) For the time being, if you want to actually **see** something rendered now, today... osgSlug ( https://github.com/AlphaPixel/osgSlug ) is the most complete way. There is a pure OpenGL demo included with Slughorn to show how you can integrate the library with any 3d rendering backend fairly easily. You don’t need a whole scenegraph, but you CAN plug it into almost any scenegraph or rendering toolkit.

- PERFORMANCE! People will want to know…we have many optimization ideas, but we’re focusing on “correctness” beforehand. We have done whatever we can to anticipate performance issues that can be addressed from the start, but there are a lot more that can be done.

- QUALITY: The purpose behind on-GPU glyph rendering is to make sure you never see blurs, texels or artifacts from other techniques like symbol atlases, SDF or MSDF or similar approximations of glyph-curve rendering. Slughorn and slug render the ACTUAL GLYPH CURVES. Perfectly. And efficiently. From any angle or perspective.  This is really important when you don’t 100% control the view matrix, especially in 3D UIs and in VR/AR, where the user could be looking at a textual element up close in an oblique perspective that you can’t fully constrain.

- We know that in modern graphics development, the push is to do everything on GPU that possibly can be done there, and this has been one of our design paradigms from the start.

- We can embed shaders into glyphs, and animate transforms and deformations, all on-GPU with no CPU workload.

- Extensive layering, blending and combining of content is possible and easy, making amazing high-definition animated 3D HUD-type effects a joy.

- EMOJIS! COLRv0 and COLRv1 emojis using the slughorn/freetype.hpp backend. Each layer of the emoji is composited into its own quad and positioned relative to the base.

- HUDS! Animated HUDs are super clean, beautiful and easy in full  3D. They work great in stereo or multi-view too.

- Animated glyphs, layer effects, morphing, 2D ortho projection, text-along-path

What’s next? See the whole PDF we produced about it, but some of the hot future wishlist items we foresee are:
Obvious Improvements: HarfBuzz & Text Layout, Stroke Caps & Joins, Patterns, SVG/NanoSVG Improvements, WebAssembly, Offline Editor (slughorned), Additional Renderers, Text Fallbacks

Research & Experimental Improvements: Performance, GDAL Backend and rendering curve/stroke map layers, SDF/MSDF Fallbacks, Interactivity Layer, UI Widgets (ImGui)

This is not a one-shotted AI slop project. It represents months of human development and years of human experience.  AI tools were used to assist with documentation and ancillary assets at times, and in code research, but this code was written by Jeremy “Cubicool” Moles, the author of text and glyph-centric tools like osgCairo and osgPango.

What we're *really* hoping for at this phase is community feedback. Beyond text, which we KNOW Slug is amazing for, what other kinds of things would you like to see? Where do you use vector graphics in your own GL/Vulkan/DX projects, and what kinds of things do you wish you could do more easily? If your only interest is text Slughorn can meet those needs no problem. But what we're really trying to do is "push" the Slug optimization into new areas, and we honestly believe we're only scratching the surface of what's possible.

Would love to hear people’s thoughts about this project.

Obviously, we (AlphaPixel) are a commercial consulting and development company. We made Slughorn to help us make a living. All of the work in Slughorn so far was done pro-bono, funded only by AlphaPixel, for the benefit of the community. If you want assistance integrating Slughorn into an existing app, we’re the obvious, world-experts in doing so, and we’d love it if you’d consider contracting us to assist you. We can probably integrate it into an existing codebase at a better net cost than having your internal developers do it, and the result will likely be better too. Also, if you find something Slughorn needs to do better (there’s lots of room for improvement, certainly) or want enhancements created, we’re the obvious candidate for that type of work too. Please consider asking us for a bid. Remember, you don’t pay anything up-front for Slughorn, and the MIT license allows you to use it in perpetuity with no recurring costs.

I recently got Eric Graham's explicit permission to put the code on GitHub for posterity, as the only copy I could find online (archive.org 7-zipped ADF) wasn't very accessible to most people.

https://alphapixeldev.com/recovering-eric-grahams-1987-amiga-juggler-raytracer-source-code/

Found on a neighbor's property at 8000ft in Jefferson County between Evergreen and Conifer.

There is a log cabin ruin about 300ft away.

It's slightly ornate, beyond just practical shape. The four iron sub pieces can spin on the bolt axle, however, the bent "handle like structure, which is partially broken off, would (if unbroken) prevent even the smaller armatures from spinning even 180 degrees.

The two larger armatures have a lip on one side, facing each other. This lip seems like a centering rim almost like it would support a cylinder between them. Picture a toilet paper tube holder, except it's clearly not that and the bolt isn't long enough obviously.

There are what appear to be countersunk screw holes on the three more ornate armatures. The fourth one is a plain rectangle with no holes other than the center. It does taper slightly in thickness to the ends.

So, in the early 90s I was a PCTECH at McMurdo station, Antarctica and worked alongside a guy named Al Oxton. There was a game we (the InfoSys group) played for fun on DOS (we were all DOS + NetWare at the time) called LAN-LOK that Al had brought from Palmer station (the smallest US Antarctic base). He didn't write it, but he was the antagonist of the game.

I kept a copy on floppy for many years and later moved it to my archival hard drive and eventually noticed it on my NAS last year. I decided to try to reconstruct and document the known history of it, since it appears to be the holy grail of lost media -- lost POLAR media.

https://alphapixeldev.com/lan-lok-the-antarctic-dos-sabotage-game-lost-for-34-years-part-1/

I include the actual EXE and instructions for how to play it under DOSBox, so you can play today!

I contacted all the guilty parties (the original authors) and they no longer have the source or executable and gave me permission to do whatever I wished with it.

In the future, I'd like to decompile it, revise it so it can be played natively on modern platforms like Linux, Windows, Mac and maybe web, and open-source the results. Maybe put it on Steam as a free game for fun. Anyone wishing to participate in that, let me know.

I hope you enjoy it. The game is actually fun in the sense that it's very on-point for 90s LAN interaction (manually typing hostnames, costly typos, chaos).

Walk of shame.

Nice paint job.

Hope everybody was OK.

Challenge completed successfully.

I feel like the gang should contact the current resident and put a qr code in the window for donations to the current occupant for pints at Greyfriars' Bobby pub around the other side.

I genuinely have no idea what this is. Hood badge didn't look familiar at all. Styling does not look American, but left had drive so not British.

Yeah, that's Sonic back behind it.