As suspected - this was a little slow, and can be corroborated with
Hotspot. This is only a marginal increase in performance, it isn't huge
but still worth doing.
Apparently we were reading packed booleans wrong the whole time
(whoops!) They are packed into *bytes*, oops... That is fixed now, and I
also expanded write support for packed booleans. It makes the assumption
that the byte is always at the end of the row, but I think that's OK for
now.
I also added a good test-case for this, the PhysicsGroup EXD. It has a
lot of rows, and some packed booleans thrown in. The columns also have
out-of-order column definitions (as in, their offsets don't increase in
order.)
Now we can re-create OpeningSystemDefine, and is added as a new test
case to test reading/writing string columns. This was actually quite
fun, it turns out that they like aligning the data sections to a 4-byte
boundary for some reason.
Expanding upon the EXH tests of this same data, we can successfully
write it back (hence why it's testdata now!) A lot of the writing logic
is specific for this EXD, but it's a start.
I updated our dependencies like binrw to 0.15, which is pretty nice as
that means we no longer depend on Syn 1.x. I also finally upgraded to
bitflags 2.x, which doesn't really mean anything except we're on
better supported version.
Additionally, I removed some bitrotten code that no longer compiles.
This was mostly benchmark stuff, but since I don't actively keep track
of that I felt it was better to remove it. I can always add it back once
I'm ready to tackle that again.
Apparently X-Patch-Length is only for the base repository, and so isn't
a reliable indicator. But it's pretty simple to add them all together to
get a close number.
This simplifes the handling of "new installs" in applications like
Astra, who may end up calling GameData::apply_patch on an "invalid"
GameData struct. We should allow applications to still hold onto these
so it keeps track of game_directory.
I was struggling to think of a way to categorize these for a while, but
I believe these are referred to as "SaveData" internally. Anyway, that's
a good name!
This adds initial support for writing new/modified maps, which are made up of layer groups (LGB) and terrain (TERA). Neither one is really tested yet, but I started checking some simple examples and it seems to work.
