Hackaday Links: March 10, 2024

March 10, 2024 by Dan Maloney 17 Comments

We all know that we’re living in a surveillance state that would make Orwell himself shake his head, but it looks like at least one company in this space has gone a little rogue. According to reports, AI surveillance start-up Flock <<insert gratuitous “What the Flock?” joke here>> has installed at least 200 of its car-tracking cameras on public roads in South Carolina alone. That’s a serious whoopsie, especially since it’s illegal to install anything on state infrastructure without permission, which it appears Flock failed to obtain. South Carolina authorities are making a good show of being outraged about this, but it sort of rings hollow to us, especially since Flock now claims that 70% of the population (of the USA, we presume) is covered by their technology. Also, police departments across the country are in love with Flock’s service, which lets them accurately track the movements of potential suspects, which of course is everyone. No word on whether Flock will have to remove the rogue cameras, but we’re not holding our breath.

Continue reading “Hackaday Links: March 10, 2024” →

The Juggler: In Rust

March 4, 2024 by Dave Rowntree 12 Comments

Back on the theme of learning to program by taking on a meaningful project — we have another raytracing demo — this time using Rust on the Raspberry Pi. [Unfastener] saw our previous article about writing a simple raytracer in spectrum BASIC and got inspired to try something similar. The plan was to recreate the famous juggler 3D demo, from the early days of 3D rendering on the Amiga.

The juggler story starts with an Amiga programmer called [Eric Graham] who created ssg, the first ray tracer application on a personal computer. A demo was shown to Commodore, who didn’t believe it was done on their platform, but a quick follow-up with the actual software used soon quelled their doubts. Once convinced, they purchased the rights to the demo for a couple of thousand dollars (in 1986 money, mind you) to use in promotional materials. [Eric] developed ssg into the popular Sculpt 3D, which became available also on Mac and Windows platforms, and kick-started a whole industry of personal 3D modelling and ray tracing.

Anyway, back to the point. [Unfastener] needed to get up the considerable Rust learning curve, and the best way to do that is to let someone else take care of some of the awkward details of dealing with GUI, and just concentrate on the application. To that end, they use the softbuffer and winit Rust crates that deal with the (important, yet frankly uninteresting) details of building frame buffers and pushing the pixels out to the window manager in a cross-platform way. Vecmath takes care of — you guessed it — the vector math. There’s no point reinventing that wheel either. Whilst [Unfastener] mentions the original Amiga demo took about an hour per frame to render, this implementation runs in real-time. To that end, the code performs a timed pre-render to determine the most acceptable resolution to get an acceptable frame rate, achieving a respectable 30 or so frames per second on a Pi 5, with the older Pis needing to drop the resolution a little. This goes to show how efficient Rust code can be and, how capable the new Pi is. How far we have come.

We saw another interesting rust-based raytracer a while back, which is kinda fun. We’ve also covered rust in other applications a few times, like inside the Linux kernel. Finally here’s our guide to getting started with rust, in case you need any more motivation to have a crack at this upcoming language.

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!