This is a big API change, and it's probably not in it's ideal
shape right now. Physis makes a big assumption that the pool of
game data that you're reading from is in the compressed, SqPack
format like in retail. However, as the projects that use Physis
expand - so does the scope of data people want to punt into it.
For example, we have Icarus that makes it easy to read Excel data
but it can only do so through SqPack which makes it less useful in
scenarios where you want to read unpacked Excel modded files or
perhaps Excel data from the network.
So I created a Resource trait that GameData now implements (and
it's now called SqPackResource.) In a similar vain, Physis comes
with an UnpackedResource and a ResourceResolver to chain multiple
Resources together.
I broke this when changing a split to split_once I think, and it stayed
broken longer than it ever should have. To stop that from happening
again, more tests are added to catch this.
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.
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'm an idiot, these row ids are here for a reason and are important for actually
reading Excel sheets. The API has changed to a read_row() function that takes a
row id, and I'll improve it before release.
This is to make way for another dat module (for the stuff under the user
folder.) This kind of re-organization was inevitable anyway, and I gave the
structs new SqPack-y names to fit their new home.
Now it reads much more of the index file format, and tries to handle
index1/index2 differences more opaquely. I'm not yet happy with the API, it
needs a bit more work.
So we had a couple copies of a Platform enum, so now there's a public
one in the common module. It wasn't possible to specify what platform
the GameData is, so now it's part of initialization. While I'm at it,
remove the stupid reload_repositories() requirement and make that a
private part of the API.
We can simplify some of the repository code since there's now two
separate functions for base/expansion repositories. Added tests to make
sure reading doesn't regress like it did before.
In Hotspot it was revealed that a huge chunk of performance is lost due
to repeated IndexFile::from_existing calls, which may be on the same
index file. Now GameData transparently keeps a cache of these in memory
which speeds up the slowest link here.
Currently, we not handle repairing version files well, so I
sought to seek a solution to the problem. This is one of part of the
puzzle, by implementing a simple "game repair". This is not
IndexedZiPatch support, but simply checking if we can restore version
files if possible, or otherwise wipe the directory.
