This topic picks up from my work here: Porting Arduboy Games to the WASM-4 - #18 by Dreamer3
I wonder if anyone would be interested in working on / developing for a fantasy Arduboy runtime (not an emulator!). The WASM-4 project is close and what got me inspired. The original question was how quickly could I port an existing Arduboy game to run on WASM-4. It took about an afternoon to get Mystic Balloons running smoothly. Today it took about 10 minutes to change the resolution to 160x80 and recompile.
The thing that makes WASM-4 different from most other fantasy consoles is you’re working in lower-level languages and compiling to WASM binaries - so it can be trivially easy to port an existing Arduboy C++ game where porting it to an entirely different language would be a huge ordeal.
Mystic Balloons running at 160x80
So now I’m imagining what a fantasy Arduboy “Remastered” (as it’s own thing) might look like. Instead of “porting” to WASM-4 where one might say “Hey now my game runs on WASM-4” the WASM-4 runtime itself could be slightly modified to support our specific goals and “hardware”, becoming an Arduboy runtime. So you’d be recompiling your games with Arduboy Remastered as the target, not WASM-4. I could even imagine using
#ifdef and such so that the exact same codebase could compile for an Arduboy original or Arduboy Remastered.
I’m imagining just a modest bump in specs:
- 160x80 (2:1) or 160x90 (16:9) resolution
- 32kb-64kb RAM
- 64kb cartridge size
- 1-2kb EEPROM (per cartridge/game)
- 2-bit greyscale, allowing 3 shades of grey (plus black)
Or if we wanted to go 16:9 for 160x90, that’d also be nice I think. Personally the 2:1 has always bugged me a little in how wide it is. Many “large world” scroller type games (like Balloons) could simply expand their viewport a bit to take quick advantage of the bigger screen. Sticking with 2-bit color allows us to leverage all the existing WASM-4 stuff (which is 2-bit color)… I’m not interested in maintaining a full fork of the WASM-4 project, but perhaps rather a few tiny patches here and there. Thankfully IMHO I think it’s already very well suited for this. To me the less we have to change the more we benefit (and perhaps also are more likely to be able to give back).
Why so much RAM? It’s partly because of the WASM (Web Assembly) architecture. Because WASM (as a runtime) doesn’t make a distinction between ROM and RAM, there aren’t two address spaces. Any images and assets you compile into your game have to exist in RAM. So an Arduboy game with 16kb of assets is automatically going to use 16kb of RAM to store/access them when it’s running in a WASM environment. So, yes it’s a lot more than 2.5kb, but practically speaking it’s no where near a full 64kb if your game has lots of data/assets.
I was imagining I might start by releasing my “half-remastered” version of Mystic Balloons, with just the higher resolution graphics and perhaps one to two small tweaks. I don’t really have the time to remaster all the graphics to greyscale… if someone else would like to help with the graphics work, I’d love to talk - just reach out. I imagine we could get your name added to the credits screen.
Neat things about WASM-4 and it’s road map (that we’d benefit greatly from if we made a small fork of the runtime):
- Runs in the web browser
- Runs natively (the goal is to support low powered micro controllers)
- Language agnostic - supports AssemblyScript, C/C++, Rust, Go, Nim, Zig, and more.
- Has “compatible” minimal specs even before any patches: 160x160, 2-bit color, 64k cartridge, 64kb RAM, NES like music, etc…
- There is talk of including a built-in editor of some sort.
- Working on better music/tracker support in the future.
If you want to see what Mystic Balloons looks like running natively check out my port: Mystic Balloons - TEAM a.r.g. ported by Josh Goebel