Users need a way to distinguish between when a save is needed for actual data changes to their rom, vs when a save is needed because they've made changes to their metadata but not their rom.
When working with data that can be decoded but the end of the compressed data doesn't terminate correctly, we can still view the sprite/palette, but can't easily edit them, since the format is invalid.
When opening the image editor (or editing a palette in either the image editor or table tool), repoint invalid data as a new run and make it valid. This does a few things:
* Only the current pointer will be updated. Any other pointers to the bad data will remain the same, and the bad data will be left alone. If this is the only pointer to the bad data, it will _still_ be left alone, with only the new copy being used by the pointer. This ensures maximum compatibility, even if there's things going on that HMA doesn't know about.
* When coming from the sprite tool, nothing will be repointed upon opening the image editor, since that edit happens from the address and not from a pointer. When editing the image at this point, any required moves will update all known pointers at the same time.
* When any compressed data gets rewritten and moved, the user gets notified.
If the palette is expected to be page 0 but the tilemap actually uses some other page, the sprite editor would crash when editing because of the mismatch. Make it more robust.
This is useful if you want to view multiple locations in the same rom at the same time. This was previously possible by following a pointer into a new tab, but often the thing you want to see isn't available from an onscreen pointer, so it makes more sense to open up a new goto.
* Don't show the tile palette selector for 8-bit tilemaps
* Do allow bucket fill from color 0
* Do allow 8-bit image import to include more than 16 colors in a tile
The current implementation of Diff just compares the file with the original version of it, and then highlights the bytes that have been changed since last save. Nothing fancy, but it should allow us to test the current thumb routines.
Initialization happens on a background thread. We want to be able to run commands when initialization is complete. The way this was done before wasn't very thread safe. The new version will always run the command.
* If initialization is complete, it runs the command right away.
* If initialization is not complete, it defers execution until initialization is done.
* Initialization is measured in scopes. An inner scope will not run initialization work when it's done, since there's still more initialization work that needs to be completed.
* Things like "goto" will now defer execution until initialization is complete. For most users, this won't matter. For speed users, it means that goto will now work the way they expect.
Streams now have the ability to express a "visualization" of the stream, which is a list of PixelViewModels. The table tool will display those in the background of the textbox, over to the right.
* If we serialize a bit array (for example, for tooltips in the goto menu) with an unknown source, don't crash: just show it as hex.
* Transparently save metadata after a version update.
* Don't crash if a eye-dropper selection starts out of range.
Image Editor tabs had a header tooltip that described the image loaded in them, but it only worked if the image came from a named table. Now images that are directly anchors will also have tooltips, and if the image has no anchor the original address will be used.
* When checking a dictionary for a case-insensitive key, go ahead and check with matching case first, since that's a much faster check.
* Don't spam-query the palette during the swap-step while dragging pixels around with the selection tool.
There is a second format for compressed tilemaps, where each tile gets only 1 byte instead of 2. This allows for a reduced number of tiles and no h/v flipping, but can save space.
This change implements the ability to import tilemaps with that format, as well as allowing the image editor to work with tilemaps of that format.
Emerald's townmap's tilemap uses only one byte per tile instead of the usual 2 bytes per tile. HMA can now read this format, but I can't write it yet. That'll be the next change hopefully.
If a sprite is being edited and the same sprite is used elsewhere in the same table, allow update using the palettes of the other elements as well. Example: potion, super potion, and hyper potion all share the same sprite.
If a palette is reordered, reorder other palettes used by the same sprite as well. This matters because all the palettes need to be updated or the edited sprite will look wrong.
Don't allow editing default palette
Keep palette collection palette page in sync as the page changes
Keep palette collection has-multiple-pages in sync with image editor
Fix bugs in Fill for non-0 pages
Some tilemaps have a page-offset that means that they don't use palette 0 for colors. But they may still use palette 0 for transparency. Allow tilemaps to always set a tile to palette 0.
