The grand library plan

[Hejsil]

One of the main reasons for making the Pokémon randomizer from scratch, is that I'm not satisfied with the current tools available for both Pokémon rom hacking, but also more general rom hacking. I think the real problem is that there is no proper sharing of resources between tool developers. Most Pokémon hacking tools are closed source, and abandoned.

The projects that are open source are all hard-coded applications that were never designed as libraries. Things such as ndstool which have excessive global state in the same file as main, makes it pretty hostile to try linking against its functionality.

To make it worse information, about the rom's structure are scattered across forums, making it hard for anyone, not deeply involved in those, to get into making tools. I spend 5-6 hours finding information about the layout of Pokémon trainers and their party in Black/White.

So here is the grand plan for the randomizer.

• Most functionality not strictly related to randomizing the games will be turned into libraries.
  • This has always been the goal, and a lot of the code is therefore already library friendly (A final look over the public interface for each library is required though).
  • All these libraries should expose C interfaces, so they can be used across "all" languages.
• The randomization logic will be a Zig only library specifically made with UI in mind.
  • This library is Zig only, as it heavily relies on generics to reduce code duplication.
  • The randomizer code should be able to report progress and collect useful state for error messages.

Here is a list of the libraries planned to be extracted from this repository:

• libnds: A library for extracting all information about nds roms into memory, and saving it back to disk after modifications have been made.
  • Some work is required to make libnds use less memory, as right now, it loads the entier nds rom into memory, which can be up to nearly 1G.
• libpokemon A library for exposing the Pokémon data structures from all main line Pokémon games (or at least up til gen 5).
  • This library will depend on libnds for generation 4-5 support.

Other potential, but less important, libraries that might be extracted as well:

• The utils folder contains functions used across both libnds and libpokemon.
• zig-clap is already being extracted. It is not ready for any real use yet.
• zig-crc has been fully extracted into a small lib for creating CRC specs and calculating hashes from those specs. There is also the "memory error handling" aspect of CRC which I'll probably not write myself as libnds doesn't required that functionality (and I'm not that educated in how all that works yet).
• libgba and libgb might also become small libraries if enough general functionality can be exposed for those roms.

[andrewrk]

All these libraries should expose C interfaces, so they can be used across "all" languages.

This is an important use case of Zig that you might be the first one really exploring in an in-depth way. I'll pay close attention and try to be on top of any issue reports that come up blocking this goal.

I'm planning on doing the same thing for libsoundio.

Hopefully I'll have a nice zig package manager working for you when you want to make all your libraries available :)

[Hejsil]

A thing to note. devkitPro has a few libraries for the nds, gba and others. I've skimmed over them, and there are a few interesting ones.

libfat seems to be a low-level library for reading the file allocation table of different consoles (nds included). As far as I understand, this is meant to run on the platforms themselves, so I don't think there is an overlap between that, and what I'm doing.

libnds and libgba seems to be for interfacing with the nds/gba hardware. I should probably pick another name that libnds and libgba. libndsrom maybe?

Also relevant is the Getting Started/devkitARM.

I'll look more into devkitPro's tools later.