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?
In a slightly safer departure away from jetpack roller-skating and flinging around bolts of lightning, [Ian Charnas] has been hacking retro video games. After a lot of hard work [Ian] has managed to add pose estimation to control the character in the NES boxing game “Punch-Out.” Surely he can’t get hurt doing that? No, but since it wasn’t fair to hurt the poor suffering characters, without taking any damage himself, he added electric-shock feedback to give the game a bit more, ahem, punch. See, you can get hurt playing video games!
By starting with Google MoveNet, which is a pre-baked skeletal tracking model which can run in a browser using TensorFlowJS, he defined some simple heuristics for the various boxing moves usually performed with the game controller. Next, he needed to get the game. Being a all-round good guy, [Ian] bought an original copy of the game cartridge to obtain the license, then using the USB CopyNES from RetroUSB, dumped out the game binary for the next step.
It took [Ian] around two months of disassembling the game binary, and figuring out the game logic around the characters in order to slow them down enough to make it playable, but he did manage it. You can be the judge, since he bought a bunch more cartridges to unlock more license copies, you can play it too. Just don’t add the electric-shock part, nobody needs to be administered electric shock therapy from a two inch high bright orange Mike Tyson!
Continue reading “Hacked Punch-Out Controlled With Actual Punches”
Love it or hate it, the capabilities of your modern web browser continuously grow in strange and wild ways. The ability for web apps to work offline requires a persistent local storage solution and for many, IndexedDB is the only choice as it works across most browsers and provides a database-like interface. However, as [James Long] found, IndexedDB is painfully slow on chrome and limited in querying ability. He set out to bring a tool he was familiar with, SQLite, and bring it to the web browser as absurd-sql.
Why absurd? Partially because most browsers (not chrome) implement IndexedDB on top of SQLite. So for many browsers, it is just SQLite on top of IndexedDB on top of SQLite. Luckily for [James] there already was a project known as sql.js that uses emscripten to compile the C-based SQLite into WebAssembly. However, sql.js uses an in-memory storage backing and all data is lost when refreshing the page. [James] tweaked SQLite’s method of reading and writing blocks. Instead of being memory backed, he added a layer to read and write blocks from IndexedDB. This means that only sections of the database need to be read in, bringing in huge performance gains.
That brings us to the other reason why it’s absurd. On chrome (as well as Firefox), absurd-sql beats IndexedDB on almost every benchmark. A query like
SELECT SUM(*) FROM kv led to stunning results.
So what’s the downside? Other than a somewhat large WebAssembly file that needs to get downloaded (409KB) and cached, there really isn’t. Of course, it’s not all roses when it comes to web development. Native SQLite runs 2-3 times faster than absurd-sql, which demonstrates how slow IndexedDB really is.
atomics.wait() allows the worker to block main thread execution until the read or write has finished. From the perspective of SQLite, the operations are synchronous. IndexedDB provides transactions so multiple connections can happen (for example multiple tabs open). Multiple readonly transactions can occur in parallel but only one readwrite transaction can be in flight.
Why not pull up your browser and start playing around with it? You’re already doomed to learn WebAssembly anyway.
The electronics hobby has changed a lot since the advent of the microprocessor. Before that — and with the lack of large-scale integrated circuits — projects in magazines tended to be either super simple or ultra complex. However, one popular type of project dealt with music synthesis. Fairly simple circuits could combine to make a complex synthesizer so it was sort of the best of both worlds. Nowadays, you are more likely to tackle a music synthesizer in software like [Tim] did when he created Abelton in Web Assembly and C++. Along the way, he learned a lot about the relationship between math and music.
[Tim] covers what he learned about the Nyquist theorem and how to keep synthesis data flowing in real time with buffers. However, there are some problems trying to do all this in a cross-browser context. The
AudioWorklet class appears to have widespread support, though, and [Tim] managed to get that working.
Continue reading “Web Assembly, Music Synthesis, And The Beauty Of Math”
The compiler is free to use for GPLv2 projects. If you aren’t open yourself, it looks like you have to cut a deal to use Cheerp with its maker, Learning Technologies.
Continue reading “C++ Compiler Targets The Web”
The joys of overengineering a simple gift. [Joren] wanted to create a dress for his daughter’s fourth birthday that would react with lights in sequence for a song from Frozen. The dress and an LED strip, along with a digital microphone and a battery were easy to procure. But how to make it all work? An ESP32 did the trick.
While the project’s name–Olaf–sounds like it was from Frozen, according to the GitHub page it actually means Overly Lightweight Acoustic Fingerprinting. Right. However, as the name implies, it can learn to identify any sound you want.
Continue reading “Olaf Lets An ESP32 Listen To The Music”
If you keep up with the field of web development, you may have heard of WebAssembly. A relatively new kid on the block, it was announced in 2015, and managed to garner standardised support from all major browsers by 2017 – an impressive feat. However, it’s only more recently that the developer community has started to catch up with adoption and support.
So, what is it? What use case is so compelling that causes such quick browser adoption? This post aims to explain the need for WebAssembly, a conceptual overview of the technical side, as well as a small hands-on example for context.
Continue reading “WebAssembly: What Is It And Why Should You Care?”