Texture writing overhaul

[sauraen]

PR which overhauls F3D texture writing. These changes were originally started for the following reasons:

• Effectively move whether textures are CI and the CI format from being a per-texture property, to a property shared by both textures, as this is how it is implemented on the RDP. The texture formats are still set per-texture, but a GUI warning is shown and an error is thrown at export if one texture is CI while the other is not, or if the CI formats (RGBA16 or IA16) are different. The othermode bits to set CI and CI format are moved from being written separately with each texture to being written with the other othermode bits, saving 1-2 instructions per material DL.
• Allow for two CI4 textures with different palettes to be used together as multitexture (this works on N64, but in fast64 before this PR, it would try to combine them into one palette and fail if there were more than 16 different colors).

This turned into a full overhaul of the texture writing functions. This includes improved support for:

• Texture references
• Flipbook textures
• Large textures
• All combinations of the above

Functionality is now separated into the following steps:

• Fetching basic texture information (for the othermode bits as well as further uses below), and validating some texture properties and conditions.
• Determining how to arrange CI palettes in the upper half of TMEM, including handling of ALL cases of mixed formats (e.g. CI4 + CI8), texture references, export as PNG mode, and palette merging
• Determining how to arrange texel data in the lower half (or all) of TMEM (if two textures are the same)
• Generating or getting texture and palette definitions
• Writing DL entries, including separate handling of the "load" and "set tile" steps
• Writing actual texture data

This overhaul was necessary because with the existing code organization, the information needed to make the decisions with CI textures (e.g. whether the union of the colors used in two CI4 images was greater than 16 colors) was only available deep within the functions writing the textures. The new code is also often simpler and more modular.

This PR is not expected to conflict with the material bleeding PR, as I still use the standard GBI classes.

[Zelllll]

I actually have a question about this. Do you know if having a single CI texture as both texel0 and texel1 works still?

[Dragorn421]

Suggested change

	allImages = []
	for flipbookTexture in flipbookProp.textures:
	if flipbookTexture.image not in allImages:
	allImages.append(flipbookTexture.image)
	allImages = list(set(flipbookTexture.image for flipbookTexture in flipbookProp.textures))

[sauraen]

Unfortunately this does not work--the set will scramble the order of the items. For multiple materials using the same texture, it matters what order the textures are in the use list. Python is unfortunately missing a native list function to remove duplicates keeping the first instance of each.

[Dragorn421]

was removing the _pal suffix intentional?

[sauraen]

Names have since been completely overhauled (they're basically what they used to be, including the _pal suffix).

[sauraen]

This PR works with all kinds of texture formats as tested with the test scene (see the video). However, it needs to be tested with SM64, especially the TexRect feature. If someone who has a SM64 mod could export one of their scenes with this branch and confirm it doesn't break, that would be great.

[sauraen]

bozies exported the museum test scene in SM64 (in an emulator), and it worked fine. If someone could test TexRect that would be great, but otherwise this is reasonably well tested.

[sauraen]

The mat bleed changes are now merged into this, and it is now up to date with top-of-tree. Needs review.

Note that OoT scene exporting currently corrupts scene_table.h. This is an unrelated bug not caused by this PR (it's in main).

[thecozies]

Mostly just requests for some small cleanup but nothing blocking in of itself. There seems to be an issue with mat bled textures, both with scrolling and large textures but i havent figured out exactly whats going on. I'll post a separate comment with info.

I can see some potential issues with some of the messaging to users. I think the large texture creator may be a little overwhelming in its language to some users. Not a blocker, but something we should respond to as we get user feedback on the feature.

[Dragorn421]

This change was made without updating a bunch of TextureFlipbook instanciations such as
TextureFlipbook(arrayName, "Array", textureList)
which breaks a bunch of code