A Journey Through Font Rendering

January 7, 2024 by Matthew Carlson 8 Comments

In the wide world of programming, there are a few dark corners that many prefer to avoid and instead leverage the well-vetted libraries that are already there. [Phillip Tennen] is not one of those people, and when the urge came to improve font rendering for his hobby OS, axle, he got to work writing a TrueType font renderer.

For almost a decade, the OS used a map table encoding all characters as 8×8 bitmaps. While scaling works fine, nonfractional scaling values are hard to read, and fractional scaling values are jagged and blocky. TrueType and font rendering, in general, are often considered dark magic. Font files (.ttf) are structured similarly to Mach-O (the binary format for macOS), with sections containing tagged tables. The font has the concept of glyphs and characters. Glyphs show up on the screen, and characters are the UTF/Unicode values that get translated into glyphs by the font. Three critical tables are glyf (the set of points forming the shape for each glyph), hmtx (how to space the characters), and cmap (how to turn Unicode code points into glyphs).

Seeing the curtain pulled back from the format itself makes it seem easy. In reality, there are all sorts of gotchas along the way. There are multiple types of glyphs, such as polygons, blanks, or compound glyphs. Sometimes, control points in the glyphs need to be inferred. Curves need to be interpolated. Enclosed parts of the polygon need to be filled in. And this doesn’t even get to the hinting system.

Inside many fonts are tiny programs that run on the TrueType VM. When a font is rendered at low enough resolutions, the default control points will lose their curves and become blobs. E’s become C, and D’s become O’s. So, the hinting system allows the font to nudge the control points to better fit on the grid. Of course, [Phillip] goes into even more quirks and details in a wonderful write-up about his learnings. Ultimately, axle has a much better-looking renderer, we get a great afternoon read, and fonts seem a little less like forbidden magic.

Maybe someday [Phillip] will implement other font rendering techniques, such as SDF-based text renderers. But for now, it’s quite the upgrade. The source code is available on GitHub.

Building A Weather Display In Rust

September 29, 2023 by Bryan Cockfield 21 Comments

We’ve seen a lot of weather displays over the years, and plenty of the more modern ones have been using some form of electronic paper. So what makes this particular build from [Harry Stern] different? The fact that the firmware running on the ESP32 microcontroller at its heart was developed in Rust.

The weather station itself is capable of operating for several months on its rechargeable NiMH battery bank. The Rust section of the project is in two parts, the first of which runs on a server which downloads the weather data and aggregates it into an image. The second part runs on the ESP32 using esp-idf which configures peripherals, turns on and connects to Wi-Fi, retrieves the image from the server, displays the image and then puts the display to sleep. By doing the heavy lifting on the server, the display should be able to run for longer than it would if everything was happening on the ESP32.

The project code is available from this GitHub page which should allow even Rust beginners to follow along, and the case file is also available for those with a 3D printer. [Harry] has a few upgrades planned for future releases as well, including a snap-fit case, a custom PCB, and improved voltage regulator for better battery life, and enhanced error handling for the weather API. And Rust isn’t the only interesting part of this project, either. As prices for e-paper displays continue to fall, more and more of them are found in projects like weather stations and even complete laptops which use these displays exclusively.

Audio, Not Video Over The LKV373 HDMI Extender

August 2, 2023 by Matthew Carlson 11 Comments

[eta] found herself in a flat with several LKV373 HDMI extenders. Find the corresponding transmitter, plug it into your device, and you’ve got a connection to the TV/sound system, no fussing with wires behind the TV. However, [eta] wanted to get rid of the need to plug in a laptop and start sending packets directly to play music. As her flatmate [dan] had already reverse-engineered the receiver, she tested her prototype against their virtualized receiver, de-ip-hmdi.

The actual sending of images was surprisingly straightforward — just a JPEG sliced into 1024 bytes chunks and sent over. However, early testing showed nothing on the receiver. The end of a frame needed marking by setting the most-significant bit of the chunk number to one. Now de-ip-hdmi showed the image, but the actual hardware would not. With something missing, [eta] returned to Wireshark to scan packets. Noticing some strange packets on port 2067, she analyzed the pattern to reveal it sent another packet just before a new frame and included the frame number. With this tweak, it was still not enough. Ultimately, heartbeat packets sent every second synchronize things, but compared to the noise of the video packets, they were easy to miss. Now [eta] had some functioning video streaming rust code.

In theory, audio for the LKV373 followed the same thought process as video. Two channels of 32-bit big Endian integers at 44,100 hz chunked into 992-byte sections and sent as a packet formed the audio stream. With only 992 bytes, two streams, and 4 bytes per sample, each packet only held 2.812 milliseconds of sound. The first tests resulted in no audio output or distorted crunchy sound. Of course, this was every audio engineer’s worst nightmare: jitter. With a spin loop and an efficient ring buffer, the audio packets were soon slinging across the network reliably.

The code is available on a hosted version of GitLab. It’s a beautiful journey through reverse engineering some obscure but relatively cheap hardware. Along the way, there is nicely annotated Rust code, which makes it all the better.

a modern car dipped into a chemical bath for electrodeposition adding a phosphate layer

Watching Paint Dry For Over 100 Years

July 2, 2023 by Michael Shaub 19 Comments

A Model T Ford customer could famously get their car “in any color he wants, so long as it’s black.” Thus begins [edconway]’s recounting of the incremental improvements in car paint and its surprising role in mass production, marketing, and longevity of automobiles.

In it, we learn that the aforementioned black paint from Ford had so much asphalt in it that black was the only color that would work. Not to go down a This Is Spinal Tap rabbit hole, but there were several kinds of black on those Model Ts. Over 30 of them were used for various purposes. The paints also dried in different ways. While the assembly only took 12 hours, the paint drying time took days, even weeks backing up production and begging for innovation. [edconway] then fast-forwards to an era of “conspicuous consumption and ‘planned obsolescence’” with DuPont’s invention of Duco that brought color to the world of automobiles.

See the article for the real story of advances in paint technology and drying time. Paint application technology has also steadily improved over the years, so we recommend diving in to get the century’s long story.

New Tool Helps Create Laser-Cut Doom Maps

April 19, 2023 by Lewin Day 7 Comments

Doom has a larger cultural footprint than the vast majority of video games ever made. That inspired [Theor] to see if it was possible to laser-cut some of the game’s maps to create a real-world model of those famous original levels.

Level data was extracted from the game’s original WAD data files using code written in Rust. Maps are described by multiple “lumps” within the WAD file format, each containing information on vertexes, walls, and floors. This data was scraped and converted into SVG files suitable for laser cutting. [Theor] then built a visualizer that could display what a stacked-up laser cut map would look like in 3D, to verify everything worked correctly. With that done, the map could be laser cut without worries that it would come out a jumbled, janky mess.

[Theor] kept the finished product simple, creating the map as a stack of blue acrylic pieces. We can imagine this tool being perfect for creating a high-quality diorama though, with some work done to paint the map to match what the player sees in game. If you happen to take that approach, don’t hesitate to notify the tipsline!

An ortholinear keyboard with predominantly blank white keycaps. There are two red keycaps on the bottom outside corners. The center of the keyboard houses a large LCD in portrait orientation on a red PCB.

2022 Cyberdeck Contest: Keezyboost40 Is A Cyberdeck Masquerading As A Keyboard

October 20, 2022 by Navarre Bartz 5 Comments

There’s something to be said for über-powerful cyberdecks, but there’s also a certain appeal to less powerful decks squeezed into a tiny form factor. [Christian Lo] has designed a cyberdeck that looks like a simple ortholinear keyboard but is running a more flexible environment.

There are games and animations you can play on QMK, but [Lo] felt that a different framework would give him more flexibility to really stretch the limits of what this Raspberry Pi Pico-powered deck could do. He decided to go with a Rust-based firmware with the keyberon library and says, “it felt like I was in control of the firmware.” While the board is using Rust for now, [Lo] says he’s open to conversations about other firmware options to achieve his goals, like a virtual pet game for the board.

The PCB is described as “bog standard” with the possible exception of placing the Pi in a cutout on the board to keep things as low profile as possible. The trade-off comes in the form of reduced board rigidity and potentially increased strain on the connections to the microcontroller.

Looking for more cool cyberdecks? Check out the Winners of the 2022 Cyberdeck Contest or go see all the entries on the Contest Page.
Continue reading “2022 Cyberdeck Contest: Keezyboost40 Is A Cyberdeck Masquerading As A Keyboard” →

Injecting A Bit Of Rust Via DLL

July 11, 2022 by Matthew Carlson 16 Comments

Ever been frustrated that a software package was missing a feature you want? In the best-case scenario, the software would be open source and you could just tweak the code and rebuild. But in many cases, the software is closed-source. In the case of [Faster than lime], he found a SNES emulator (Snes9X) that didn’t support controllers to showcase the technique. So with a little bit of Rust, he wrote some code that could be injected into the emulator via DLL injection.

It’s a fantastic tutorial that shows the technique. He starts by creating a Rust project that uses the DLL-Syringe crate (the rust version of dependency management). This crate does much of the heavy lifting involved with injecting a DLL into a target process. The rest of the journey is an excellent process of going through the Windows documentation and implementing the features. The DLL just reads the controller and then sends the right input to the program. In the end, [Faster than lime] has a great injected DLL and we have a wonderful time learning about Rust and debugging in an injection environment!

It’s been a while since we last covered DLL injection, and it’s nice to see how the process has evolved. Video after the break.

Continue reading “Injecting A Bit Of Rust Via DLL” →