Tilemaps (and 256 color images) often need multiple palettes to render the entire thing. Palettes can now specify a start/end page in their format, expressing which slots they expect to be loaded into. This, in turn, helps the tilemap render correctly based on those slots.
* Add runs for charizard/venasaur in title screen
* Make the SpriteTool sprite scaling dynamic
* Better support for comments on the end of the line in the table reference file
*
For some roms, the sprites load at the wrong length. When the proper length is later discovered, it's important to update the length of all related tables, not just the current table.
* Emerald had the wrong pointers/length for trainer sprites
We don't support tilesets / tilemaps yet, but when we do, this is how I expect the format to work. Tilemaps need to know about their associated tilesets, which need to know about their associated palettes.
This is activated by having the enum be a sprite table, as demonstrated by each trainerdata including a field for its sprite.
-> note that since the trainerdata length now depends on knowing how many sprites there are, the sprites need to be loaded _before_ the trainerdata.
* return an error to the user (instead of crashing) if the user tries to make a compressed run use more data than it would be when uncompressed.
* Update the Sprite shown in the SpriteTool after a format change.
* Add table locations for emerald bag-type icon/palette and firered player trainer sprites
Instead of keeping tables segregated from other kinds of runs that we want found automatically, just allow all types of runs in the tables file.
Combine the typechart runs into a single run, which makes the chart easier to work with.
Sometimes, the sprites don't each have a matching palette. Instead, there's a smaller number of palettes that are shared between all the sprites. In this case, it's useful for the sprite's palette hint to be able to be a name of a table who's length matches a table of palettes. Then the palette from that palette table can be deduced from the indexing element.
* Icons in FireRed (and Emerald) are stored uncompressed. So add support for showing uncompressed images/palettes in the tool
* Since we want uncompressed and compressed images to both work in both the table tool and the image tool, make interfaces that both implement and make the tools use those interfaces.
* Not using the right palette yet, because that's using an indexed-palette system where there are far fewer palettes available.
This list appears to be a list of names for the areas. Not sure if it's connected to the overworld map, travel map, or something else. But it seems to be the only place where all the town/route names are stored in a single list.
* Remove pages/depth concept from tiles. Tiles that are a multiple of the expected size will be given multiple pages.
* Add UI/ViewModel code to support multiple pages
* decode front/back pokemon sprites, trainers, and pokeballs because why not
* fix bugs in the palette decoder
* allow for automatic pairwise-matching of images and palettes
* make palettes smaller, they don't need to be so big
* Add TileImage, a Image subclass that represents a single tile with a TileViewModel.
* SpriteArrayElementViewModel hold useful information for how to render a set of tiles.
* The SpriteFormatStruct knows how long its uncompressed data should be (in bytes)
* pokemon sprites are 8 tiles x 8 tiles, not 4 tiles by 4 tiles.
Now that the lz-compression stuff is working, it's time to finally start on pokemon sprites / palettes.
* Add two new run types that derive from LzRun, for sprites and palettes
* Add formatting code to recognize the class of pointers that point to sprite/palette data
* Add the SpriteArrayElementViewModel, which will eventually house the viewmodel sprites displayed in the UI. Don't worry about editing yet: just get them to show up.
The battle scripting commands are each an assembly routine that specifies what a specific battle script command does. Right now these are just raw pointers, but I have a feeling I'm going to want these in the future...
Each game handles the pickup tables a little differently. R/S/FR/LG store an item and the odds of getting that item (cumulative). Emerald instead stores two tables, one for common items and one for rare items. What values are used from within those tables are based on the pokemon's level.
I was considering making a feature that allowed for custom-width bit arrays. But right now this is the only data that would use it, so let's take a shortcut for now.
The tables refer to pokemon by their nationaldex number, not by their pokemon ID. So I needed a way to use an index-enum. That's the new test in NestedTableTests. That's also the reason for the change in StartCellEdit, ModelCacheScope, and IDataModel.
The new test in AutoSearchTests proves that the 4 new tables work correctly. That's also the reason for the change in StartScreen and tableReference.
'Habitat' is a pokedex feature in FireRed / LeafGreen. It involves having pokemon viewable based on where they can be caught, organized into pages, instead of just in dex order. The format is rather nested, but the table tool still works fine.
Other things should probably be in this reference file too, such as the headers, streams, and default lists. But this is a good start and should make it more expandable in the future.
