wasm

4 Articles

Bringing Zelda Classic To The Browser

May 4, 2022 by 6 Comments

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?

You Are Doomed To Learn WebAssembly

July 15, 2021 by 37 Comments

At first, Web browsers displayed HTML pages. But then people wanted those pages to do something. So we got — among other things — JavaScript. Then people wanted to do super complicated and compute-intensive things. So now we have WebAssembly. If you want to learn it, [diekmann] has a 4-part series that covers everything from getting started to porting Doom into your browser.

Paradoxically, instead of using a browser, he uses the wasm binary toolkit to run code more like a standard assembler. And wasm — what most people call WebAssembly — isn’t like most assemblers you know. Instead of labels, there are blocks that work much more like high-level language constructs such as while loops in C.

Continue reading “You Are Doomed To Learn WebAssembly” →

WebAssembly: What Is It And Why Should You Care?

April 4, 2019 by 45 Comments

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?” →

Web Pages Via Forth

August 2, 2018 by 16 Comments

Forth. You either love it or you hate it. If you have struggled to work on tiny microcontrollers, you probably are in the first camp. After all, bringing up a minimal Forth system is pretty simple and requires very little resources on the CPU. Once you have such an environment it is then easy to extend Forth in Forth. [Remko] decided he wanted to build a Forth compiler that uses WebAssembly and runs in your browser. Why? We’ve learned not to think about that question too much.

The world has changed a lot since the first introduction of the WorldWideWeb browser in 1990. What started out as a way to show text documents over the network has become — for better or worse — an application platform. JavaScript won the browser scripting language wars and security concerns pretty much killed Java applets and Flash. But JavaScript isn’t always fast. Sure, there are ways to do just in time compiling, such as Google’s V8 engine. But that compile step takes time, too. Enter WebAssembly (or Wasm).

Continue reading “Web Pages Via Forth” →