Bringing Zelda Classic To The Browser

Finding a device or app that isn’t a web browser doesn’t seem easy. These days, it is either connected to the web (looking at you ESP32) or is just a web browser pretending to be something else (a la electron, PWAs, or React Native). So, of course, it is on us to create more and more exciting things to browse. [Connor Clark] is one of those people, and he brought Zelda Classic to the browser.

Zelda Classic (ZC) isn’t an official Zelda game. Instead, it’s an old engine designed to run the world in the OG Legend of Zelda and be easily modified to support hundreds of different games. To date, there are over 600 games submitted by a large community. ZC is an Allegro-based Windows-only game, so the first step was to bust out Emscripten to start tweaking the C++ code to support a web environment. Rather than completely port the huge codebase over from Allegro, [Connor] made the jump from Allegro 4 to 5. Allegro 5 has SDL as a backend and adds support for Emscripten.

Unfortunately, the 4 to 5 wasn’t as simple as changing the dependency. The API was wholly re-written, and there is a handy adapter known as Allegro Legacy to help transition a project from one to another. After squashing a multitude of bugs, it was a relatively painless procedure. After a quick detour getting music and level data working, [Connor] faced his next challenge: multi-threading. Efforts to move the main loop off of the browser thread and into a web worker ran into issues with having to yield in loops, deadlocks, and recursive mutexes. Finally, he added music and gamepad support after fixing several bugs in SDL and Allegro.

It’s an incredible journey with many tips and tricks for debugging seemingly intractable bugs. The code is up on GitHub, or jump in and start playing if you’re interested. Why not check out this browser-based OpenSCAD as well?

Arduino And Git: Two Views

You can’t do much development without running into Git, the version control management system. Part of that is because so much code lives on GitHub which uses Git, although you don’t need to know anything about that if all you want to do is download code. [Dr. Torq] has a good primer on using Git with the Arduino IDE, if you need to get your toes wet.

You might think if you develop by yourself you don’t need something like Git. However, using a version control system is a great convenience, especially if you use it correctly. There’s a bug out in the field? What version of the firmware? You can immediately get a copy of the source code at that point in time using Git. A feature is broken? It is very easy to see exactly what changed. So even if you don’t work in a team, there are advantages to having source code under control.

Continue reading “Arduino And Git: Two Views”

A Universal, Non-planar Slicer For 3D Printing Is Worth Thinking About

One may think that when it comes to 3D printing, slicing software is pretty much a solved problem. Take a 3D model, slice it into flat layers equal to layer height, and make a toolpath so the nozzle can create those layers one at a time. However, as 3D printing becomes more complex and capable, this “flat planar slicing” approach will eventually become a limitation because a series of flat slices won’t necessarily the best way to treat all objects (nor all materials or toolheads, for that matter.)

How a 20 mm cube looks when sliced in a cone-shaped plane.

[René K. Müller] works to re-imagine slicing itself, and shows off the results of slicing 3D models using non-planar geometries. There are loads of pictures of a 20 mm cube being sliced with a variety of different geometries, so be sure to give it a look. There’s a video embedded below the page break that covers the main points.

It’s all forward-thinking stuff, and [René] certainly makes some compelling points in favor of a need for universal slicing; a system capable of handling any geometry, with the freedom to process along any path or direction. This is a concept that raises other interesting questions, too. For example, when slicing a 20 mm cube with non-planar geometries, the resulting slices often look strange. What’s the best way to create a toolpath for such a slice? After all, some slicing geometries are clearly better for the object, but can’t be accommodated by normal hot ends (that’s where a rotating, tilted nozzle comes in.)

Such worries may not be an issue for most users at the moment, but it’s worth trying to get ahead of the curve on something like this. And lest anyone think that non-planar slicing has no practical purpose, we previously covered [René]’s demonstration of how non-planar slicing can reliably create 90° overhangs with no supports.

Continue reading “A Universal, Non-planar Slicer For 3D Printing Is Worth Thinking About”

Meet The RouterPi, A Compute Module 4 Based GbE Router

[Zak Kemble] likes to build things, and for several years has been pining over various Raspberry Pi products with an eye on putting them into service as a router. Sadly, none of them so far provided what he was looking for with regard to the raw throughput of the Gigabit Ethernet ports. His hopes were renewed when the Compute Module 4 came on scene, and [Zak] set out to turn the CM4 module into a full Gigabit Ethernet router. The project is documented on his excellent website, and sources are provided via a link to GitHub.

A view underneath shows off the RTC, power supply, and more.

Of course the Compute Module 4 is just a module- it’s designed to be built into another product, and this is one of the many things differentiating it from a traditional Raspberry Pi. [Zak] designed a simple two layer PCB that breaks out the CM4’s main features. But a router with just one Ethernet port, even if it’s GbE, isn’t really a router. [Zak] added a Realtek RTL8111HS GbE controller to the PCIe bus, ensuring that he’d be able to get the full bandwidth of the device.

The list of fancy addons is fairly long, but it includes such neat hacks as the ability to power other network devices by passing through the 12 V power supply, having a poweroff button and a hard reset button, and even including an environmental sensor (although he doesn’t go into why… but why not, right?).

Testing the RouterPi uncovered some performance bottlenecks that were solved with some clever tweaks to the software that assigned different ports an tasks to different CPU cores. Overall, it’s a great looking device and has been successfully server [Zak] as a router, a DNS resolver, and more- what more can you ask for from an experimental project?

This CM4 based project is a wonderful contrast to Cisco’s first network product, which in itself was innovative at the the time, but definitely didn’t have Gigabit Ethernet. Thanks to [Adrian] for the tip!

Optimized Super Mario 64 Offers Exciting Possibilities

When working on any software project, the developers have to balance releasing on time with optimizations. As long as you are hitting your desired time constraints, why not just ship it earlier? It’s no secret that Super Mario 64, a hotly anticipated launch title for the Nintendo 64 console in 1996, had a lot of optimizations left on the table in order to get it out the door on time. In that spirit, [Kaze Emanuar] has been plumbing the depths of the code, refactoring and tweaking until he had a version with serious performance gains.

Why would anyone spend time improving the code for an old game that only runs on hardware released over two decades ago? There exists a healthy modding community for the game, and many of the newer levels that people are creating are more ambitious than what the original game could handle. But with the performance improvements that [Kaze] has been working on, your budget for larger and more complex levels suddenly becomes much more significant. In addition, it’s rumored that a multi-player mode was originally planned for the game, but Nintendo had to scrap the feature when it was found that the frame rate while rendering two cameras wasn’t up to snuff. With these optimizations, the game can now handle two players easily.

Luigi has been waiting 26 years for his chance to shine.

[Kaze] has a multi-step plan for improving the performance involving RAM alignment, compiler optimizations, rendering improvements, physics optimizations, and generally reducing “jankiness.” To be fair to the developers at Nintendo, back then they were working with brand new hardware and pushing the boundaries of what home consoles were capable of. Modeling software, toolchains, compilers, and other supporting infrastructure have vastly improved over the last 20+ years. Along the way, we’ve picked up many tricks around rendering that just weren’t as common back then.

The central theme of [Kaze]’s work is optimizing Rambus usage. As the RCP and the CPU have to share it, the goal is to have as little contention as possible. This means laying out items to improve cachability and asking the compiler to generate smaller code rather than faster code (no loop unrolling here). In addition, certain data structures can be put into particular regions of memory that are write-only or read-only to improve resource contention. Logic bugs are fixed and rendering techniques were improved. The initial results are quite impressive, and while he isn’t done, we’re very much looking forward to playing with the final product.

With the Nintendo 64 on its way to becoming a mainline-supported Linux platform, the old console is certainly seeing a lot of love these days.

Continue reading “Optimized Super Mario 64 Offers Exciting Possibilities”

Arm Pumps Up The Volume With Mbed And A Potentiometer

Last time, I told you how to get started with the “Black Pill” STM32F411 board using the Mbed OS. The example program, admittedly, didn’t use many of the features of the OS, unless you count what the USB serial port driver uses behind the scenes. However, this time, we’ll make a practical toy that lets you adjust your PC’s volume level with a pot.

The Black Pill module on a breadboard.

The Black Pill is a good choice for this application since it has analog inputs and can act as a USB keyboard. In fact, the Mbed OS has drivers for all kinds of USB devices. We’ve seen the serial port, but you can also look like a mass storage device or a mouse, for example. Just for practice, we’ll create two threads of execution. One will read the pot and send a message over to the other thread. That thread will communicate with the PC as a USB keyboard. Any computer that understands media keys on a keyboard should work with the device.

Threads

Creating threads is very simple. For many cases, you just define a void function that takes no arguments and use it with a Thread object:

readknobThread.start(vol_thread);

Of course, the function shouldn’t return unless you want the thread to end. As I mentioned in the last post, you can sleep with the ThisThread::sleep_for call. There is also a yield call if you simply want to give up the time slice without sleeping for a specific amount of time.

Continue reading “Arm Pumps Up The Volume With Mbed And A Potentiometer”

Twitch And Blink Your Way Through Typing With This Facial Keyboard

For those that haven’t experienced it, the early days of parenthood are challenging, to say the least. Trying to get anything accomplished with a raging case of sleep deprivation is hard enough, but the little bundle of joy who always seems to need to be in physical contact with you makes doing things with your hands nigh impossible. What’s the new parent to do when it comes time to be gainfully employed?

Finding himself in such a boat, [Fletcher]’s solution was to build a face-activated keyboard to work around his offspring’s needs. Before you ask: no, voice recognition software wouldn’t work, at least according to the sleepy little boss who protests noisy awakenings. The solution instead was to first try OpenCV and the dlib facial recognition library to watch [Fletcher] blinking out Morse code. While that sorta-kinda worked, one’s blinkers can’t long endure such a workout, so he moved on to an easier set of gestures. Mouthing Morse code covers most of the keyboard, while a combination of eye, eyebrow, and other facial twitches and tics cover the rest, with MediaPipe’s Face Mesh doing the heavy-lifting in terms of landmark detection.

The resulting facial keyboard, aptly dubbed “CheekyKeys,” performed well enough for [Fletcher] to use for a skills test during an interview with a Big Tech Company. Imagining the interviewer on the other end watching him convulse his way through the interview was worth the price of admission, and we don’t even care if it was a put-on. Video after the break.

CheekyKeys is pretty cool, doing something with a webcam and Python that we thought would have needed a dedicated AI depth camera to accomplish. But perhaps the real hack here was how [Fletcher] taught himself Morse in fifteen minutes.

Continue reading “Twitch And Blink Your Way Through Typing With This Facial Keyboard”