You can browse this project's development on GitHub.

pret's decompilations of the core series games has made ROM hacking easier than ever. As game source code, however, it leaves a lot to be desired for modders and fanhacking. The constraint of matching the code to the ROM byte-for-byte imposes a hard ceiling on how much can practically be improved.

nichruby is here to change all of that. By abandoning the strict constraint of binary matching and rewriting the codebase from scratch, it will provide a basis for fanhackers far more usable and extensible than what the decomps can offer long before it is complete. File-by-file, I am sifting through all of the sources of pokeruby and attempting to reimplement each module piece-by-piece, with manual consideration for structure and code quality. This will compile with current releases of devkitPro's devkitARM GCC toolchain.

Q: What are some of the benefits to this approach?

A: Being able to reorganise the repository from scratch leaves a lot of doors open that the original decomps either decided to or were forced to close. For example, they have needed a whole host of custom tooling to make pieces of data and code appear in the right places. Their INCBIN system inlines data into C source code to this end. Even the original games would not be programmed in such an awkward and brittle way.

Q: Is this just reshuffling the sources around, or is there something more to what you are doing?

A: Every module of C code is being rewritten from scratch. Furthermore, a whole new set of tooling is being created from scratch to deal with the task of compiling assets into the game binary. This is to maximise ease of use from a forward development standpoint rather than a reverse engineering one. For example, most assets will use the mangledeggs symbol mangling regime, allowing a high degree of modularity and scoping in script sources and more.

Q: How far along is this project then? It sounds useful!

A: It's a relatively recent endeavour, and I am currently the only one working on it. However, unlike the decompilations, it will be very usable by the general public long before I finish porting over the entire game! What's more, the pokeruby decompilation serves as the perfect stomping ground to understand how every part of the original game works.

Q: Great! How could I contribute, then?

A: The objective of this project is to write the best C sources we can for a game that is functionally identical to Pokémon Ruby. 'Functionally identical' goes as far as save file compatibility and what you see and hear in-game, to draw a rough but bold line. In order to accomplish this though, guidelines need to be written regarding how this is actually to be done. I don't expect a lot of help until I have those spelled out, but you're welcome to reach out!

Q: How can I keep up with this project?

A: Giving it a star on GitHub will put updates onto your homepage every time you log in to GitHub. You can also join the Fanhacker's Toolkit Discord for more incremental and instantaneous posts from me and others who are interested. I will also post significant updates about the repository and its tooling in this thread.

This is the first of hopefully many status updates regarding what I've been up to with nichruby and the FHTK. It's also a post to outline my thinking with this in-depth.

First of all, mangledeggs is complete, after a week and a half of work. I realised I needed a more well-thought-out answer to the task of symbol mangling as I was porting the gfx2o utility to C, as it uses a very hacky approach of replacing path separators with underscores.

Speaking of gfx2o, that is now what I am working on! This is a (relatively) simple program that coordinates grit and the linker. It reads in multi-dotted file extensions from sources to recognise what kind of output image is desired, creates a symbol name with the repo-relative path to the image using mangledeggslib, and then transforms it into assembly so the data can be tagged and passed to the assembler, giving us an object code file (ofile). With this tool in hand, the compilation of graphics into the ROM from human-friendly PNG sources will be easy and straightforward.

After I am done with gfx2o, I will probably be moving on to the scripting system. This is something I have a good deal of existing work on, but like the old gfx2o script, I have to dig a lot of it out of old git repos that I have luckily not lost entirely.

It will use a two-tier language system; one will be a lower-level format called 'scrip' that will try to be as close to 1:1 with the actual bytecode format in use by the games, and one will be a higher-level format that is more recognisably turing-complete, for use in game design.

I am most excited about this because both formats will truly take advantage of mangledeggs to implement scoping of identifiers with an import/export system. No longer shall scripts need to be written with hopelessly long names, lest they get lost or mistaken. Best of all, it will all play nice with ANSI C.

Until next time,

Alexander Nicholi

Affairs have been quiet, but mightily active! The past two weeks have seen massive strides made in work on unilib. What's unilib? Well, in a nutshell, it is a support library like GLib, but with greater embedded portability. It's designed to play nice on desktops and Game Boy consoles alike.

The reason I am working on this is so that it may be used in utilities like gfx2o, but of course, there is a lot more to what has been made than the library itself. Aquefir's slick documentation format has received a major overhaul, and is being used to document the APIs for unilib already. This is serving as a test run of its viability, as it is destined to be used to document nichruby itself!

As I mentioned, unilib will work well even on tiny, memory-constrained systems like the Game Boy Advance. There is a good possibility that it will see good use as a dependency of nichruby itself, once it becomes more mature. This should be incredibly rewarding for the quality of the library itself.

Once these things are ironed out and gfx2o is in a working state, the great undertaking of asset porting will begin. This is when mangledeggs, gfx2o, grit, the assembler, and the linker will all come together in concert to provide a working output of the systems they each facilitate. This will be the keystone of what I am working on now, and it will be of great use for nichruby and so much more. I am very much looking forward to this first great milestone.

Until next time,

Alexander Nicholi