Decompile pl_batt_obj NARC, document related battle_icon.c

[joshua-smith-12]

• Decompile pl_batt_obj.narc
• Implement Python scripts to build the NARC
• Rename unk_0207C908 -> battle_icon and document (some) fields

TODO:

• update any unfixed PNG files from this NARC with the correct width + palette

this is my first contribution, tried my best to keep it to a similar style as the rest of the code but I probably scuffed it a little :)

[lhearachel]

Some preliminary comments on the assets before I dig into code. Overall, I'd like to re-evaluate the structure and have a good strategy for both how we build these files back into a single NARC and also how we present them to users.

[lhearachel]

polish: Same suggestion about types/classes applies here; there is a set of terrain constants defined in consts/terrain.json, which gets compiled to build/consts/terrain.h.

...and looking at the names there, it will likely be better for us to align the names there with the names from these terrain blobs.

[lhearachel]

Some suggestions for cleaning up names

[lhearachel]

Suggested change

	static const int ov12_BallIndexToNARCMembers[][4] = {
	static const int sThrownBallSpriteResources[][4] = {

Also check if it's possible to turn this into an array of structs like these (this name is likely not unique):

struct SpriteResource {
    int tiles;
    int palette;
    int cells;
    int animation;
};

[joshua-smith-12]

I might need some advice on this one, the array gets used later as sThrownBallSpriteResources[v0][param1], so if I convert it to an array of struct the [param1] would be trying to index that struct as if it's an array

I can do something like the below and then have the array access use the array part of the union but idk if this is good style. Or is there a better alternative to make this work?

typedef union AnimatedSpriteResource {
    struct AnimatedSpriteResource_s {
        int tiles;
        int palette;
        int cells;
        int animation;
    };
    int AnimatedSpriteResource_a[4];
} AnimatedSpriteResource;

[joshua-smith-12]

Started looking at NCER/NANR, will require a couple nitrogfx changes which I will note here

red031000/nitrogfx#14
red031000/nitrogfx#15

[joshua-smith-12]

these 3 files (along with pl_batt_obj_00000079.nclr) appear to be a duplicate of the poke_ball_throw components; have not found where they are used in the code to validate

[joshua-smith-12]

these are almost certainly corresponding with the player_..._back sprites, but have not found where they are used in the code to confirm

[lhearachel]

suggestion: Can we name the internal folder something more meaningful? Maybe res/battle/graphics/objects? We generally try to avoid using the actual NARC names outside of where strictly necessary for matching (e.g., on NARC names)

[joshua-smith-12]

I've renamed the directory, I considered renaming some of the other files (pl_batt_obj.ignore, pl_batt_obj.order) but these are more directly related to the final NARC name so I've left them as-is

[lhearachel]

suggestion: Maybe we want to discuss with red about adding lz encoding as a switch on nitrogfx outputs so that we can avoid having huge ignore files like these.

[joshua-smith-12]

yeah, this would probably be helpful. i suspect there will be other large NARCs in the project with lots of compressed files

[lhearachel]

I'll write up a PR to implement this over the course of the next couple of days.

[lhearachel]

This looks generally mergeable to me at this juncture. Resolve the conflict in tools/scripts/meson.build and it should be good. I'll hold off on approval until we have the new nitrogfx option to automatically LZ-encode an output file so that we can clean up the ignore file.