Re-implement data generation for trainers #355
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR replaces the single-file-processing Python scripts for
trdata
andtrpoke
with a batch processor in C++ that uses the ROM's struct-definitions for packing. Like with the species re-implementation, the list of known files to be packed is passed to the batch-processor via Meson'senvironment
feature: https://mesonbuild.com/Reference-manual_returned_env.html#environment-envThe approach here hinges on breaking NAIX-generation away from NARC-construction. Because Meson is built on the premise static build-configuration, we can assert that a known set of files must exist at build-time, and that if this set were to change, then the configuration itself must change. This is sensible from a build-standpoint, as well, because other aspects of the game do not directly hinge on the exact contents of an archive; accessing a trainer from
trdata.narc
only requires that you know its numeric identifier.It follows, then, that changes to existing trainer data files does not affect other modules (field scripts, ROM code, etc.), but breaking the contract of what data files are built into the trainer archives does affect those modules.
Potential Concern: Environment Variable Size
Some light reorganization of the structure tree has been done in anticipation of this concern (and for neater reorganization once more trainer-related archives are unpacked, e.g. sprites), but it is still worth bringing up.
To the best of the research that I have done, the maximum limit of an environment variable is:
execve
-time on Linux: https://man7.org/linux/man-pages/man2/execve.2.htmlPATH
still running smoothly, which is much more than Windows.The environment variable constructed is a list of file-stems separated by semi-colons. As a short measurement, I wrote some Python code to determine how big the environment variable currently is with the vanilla repository:
However, a caveat to this is that there are a number of trainer data files that are, to the best of our knowledge thus-far, wholly unused in the game. It is more likely, then, that a user would re-use one of these files than make a wholly new one; even then, we are still only cresting half of the theoretical limit mentioned above for Windows.
Benchmarks
Benchmarks below are taken from local builds on my system:
From Clean
Builds from clean see a 12-second time reduction on my machine (Arch Linux
Incremental