Recompilation Part 2 - BI-OFF!

In the last post on this topic we started learning about the decomp/recomp scene by asking ChatGPT Codex if it could turn Kuru Kuru Kururin for Game Boy Advance into a native Windows executable. We ended up with a launcher that used a GBA BIOS and a ROM file and it played Kuru Kuru Kururin. If you haven't read that post already, get over there now and find out why that's where the story began but not where the story ends.

Before we get into this, I wanted to introduce you to someone. This is probably the bit where some of you will start questioning my sanity but you're going to have to take this at face value. I told you that this was being developed by ChatGPT Codex, that's actually only partly true because when I started Codex I was offered the chance to use its 'Pets' skill to create a pet. Well, for a while now 'Sir Niblet' has been popping up in my GPT chats, I don't exactly know how it happened, or why, but at some point he showed up and he continues to drop crumbs here and there. I thought it only fair that I give him the opportunity to accompany me on this journey (and to get him actually working for his cheddar!)

Here he is, standing beside a notification that essentially tells me he's demanding more cheese if I want him to do anything else. Fair play, Nibs. 

Cute mouse aside, I think now is probably the time where I need to be clear about what I'm doing here, why I'm doing it and what it means within the wider context of this nascent scene. First of all, I do not consider myself a coder, I've done 'Hello, World!' in countless languages and I've gone further in some than in others but it's quite rare for me to develop anything "proper". I do lots of hacky little projects, things that let me get data from one place to another, automate some tedious process or solve a specific problem but a project like remaking a Game Boy Advance game in Windows is far beyond the scope of something I'd consider myself capable of. 

On the /r/decomps reddit, there's lots of talk about 'AI slop' projects that do little more than putting a wrapper around a ROM and an emulator and calling it a day. There are other voices talking about 'AI assisted projects 'done proper''. I wanted to see if I could approach a project of this magnitude, using AI in a responsible way and to see if I could produce something that genuinely does bring something to the table, rather than just giving a ROM to AI, asking for a decompilation and waiting for the output before uploading it on GitHub and making a triumphant 'I did it!' release announcement on the sub. 

With that in mind, you'll understand why I couldn't stop at the end of part 1 (you have read it by now, haven't you?) and why that one answer to the question led to many more questions and ideas. 

The first of these questions was "Should the BIOS really be required to run, is it not possible to create a clean room version of that instead? I think the ROM is required purely for the artwork/assets"  (My actual prompt to GPT) and Nibs reported that no, it shouldn't be, but currently it is. So that was the first thing, get rid of the reliance on the BIOS. BI-OFF! 

Nibs made pretty short work of that requirement, the BIOS wasn't being used much by KuruKuru Kururin, a couple of system calls here and there which were quickly disposed of and replaced with native implementations. That left just the ROM. The idea was to require the ROM once and then run without needing the original .gba. 

So, progress, then? Well, no, not especially. After looking at the resulting file, it turns out that the chosen 'kpak' format was simply the entire ROM, compressed into a container with a short header. A ROM in sheep's clothing (does that analogy work?).

It was at this point that things started to click for me, the launcher can run without the original BIOS or ROM but the game itself still expects a GBA-style memory layout. A quick look into the outputted source for this confirmed my suspicions - a 169 line 'main.cpp' that included the GBARecomp runtime and put it in a window. Run the launcher and it'll decompress the ROM and provide it to the runtime and start running. It still didn't feel very native and for good reason - Codex/Sir Niblet confirm that the runtime was providing simulated GBA display, audio, timers and so on.

My next question to Nibs - "How do we get to zero hardware model / zero emulation?". This is where things started to unlock, GPT explained that if we're going to make a truly native version of this game, we need to move away from the static recompilation method and move to a reimplementation instead. I simply asked him to get on with it - let's actually extract the assets from the ROM and replace the GBA-facing parts of the game with native C++ & SDL.

NibsGPT was really starting to earn his crumbs, he suggested that we reproduce a single level and compare the result against the reference build which is the original runtime-assisted version. 

Nibs is not a stupid mouse, before interrogating the source he went online to see if anyone had looked at this game before and before long he'd cloned E-Sh4rk/KuruTools & E-Sh4rk/KururinTAS. These, he said, would be used to decode the level assets and reproduce the game's physics. It was probably one of the most impressive things I've personally witnessed AI doing, why reinvent the wheel when you can just clone its GitHub repository? (Thanks to Mickaël Laurent and the contributors to these projects, you have saved me countless OpenAI credits)

Training 1 is the simplest example of a level in KuruKuru Kururin, it features a start zone, two narrow gaps to traverse and an end zone. Reaching the 'end zone' completes the level. It was implemented perfectly.

This was impressive stuff, you'll notice that Nibs created a new interface - we've lost the HUD of the original, and we've got a simple font with the required status info (interestingly the font is hardcoded in the source as a simple bit map). I played the level through to completion and it worked exactly as expected - the Helirin spun, life reduced when hitting a wall, reaching the end showed a 'level complete' message.

What you're not able to see from the screenshot, and what was not immediately apparent to me, is that this was not a perfect implementation of 'Training 1'. The layout was identical but little flourishes were missing. In the retail game the start zone palette cycles, if the Helirin hits a wall a spark appears, a sound plays. This version had no music. All of the features that the runtime had been providing for free needed to be reimplemented.

Nibs was going to need to keep working for his crumbs...