While it's definitely something that should be explored later on when libeuropa is a larger library, and has C ABI wrappers to better foster bindings between other languages like Rust and such, for now, libeuropa is both pretty entertwined with both the C++ standard library and STL, and still in heavy development, so I think doing this isn't a good move.
This essentially is a even-more refactored version of the new eupak "Task" setup, but done in a generic way, so multiple tools can be written like eupak easily, and I Don't Need to Duplicate It Every Time.
This commit also comes with a new test binary, "toollib_test". This will be removed once it's no longer needed and I'm done sketching out the API set (and eupak is refactored to use toollib instead), but for now this provides a two-way thing:
- Allows me to hack on toollib without breaking everything
- Shows how to use toollib.
Rather confusingly, it seems like they wanted to make this backwards compatible. In practice, due to the magic fourcc being written with a different endian, it's not really. (OK well the header is the same but you get my point)
Also, for some reason, they decided to I guess jumble format types around. Thanks guys.
While it's moot since we don't read in any hot paths, std::istream already has `read(chars, len)`, which means we don't need to reinvent it poorly. It's cleaner code as well.
This more accurately reflects that it was used during development; art was probably the earliest part of the game to be finished, therefore there are lots of leftovers of older formats. Henceforth why the game can parse them.
This completely redoes the garbage flags stuff I did before. OOPS. This seems a lot closer to the format, and also exports everything Starfighter has properly.
libpixel (suprisingly) still compiles, but depends on libraries in a very annoying manner that makes EuropaTools hard to compile. Also, I don't like stb_image_write.
Replace it with some hand-done structs and the simpler/faster/better `lodepng`.
I'm not sure how I want to handle this yet, but for now, using a vector<pair<...>> is the easiest way currently to retain insertion order. Using a hash table IS probably a better idea, and I'm looking to maybe importing Boost multimaps to allow that, but for now, /shrug.
This starts the beginning of probably one of the bigger refactor jobs, and one I've been hinting at and FIXME jabbing for a while now.
Basically, tasks now are a lot closer coupled to their arguments. This is a good thing since it means that changing or adding features only requires modifying the task, not needlessly modifying main over and over.
CreateTask is the only one that works currently for this commit and has been converted to the new ITask model.
This really could be classed a "fix", since adding support for it when reading broke writing. Now we do the right thing.
This makes sector-alignment a no-op when writing other archive versions. I might make it an error to specify -s with a non-JSF package version.
As it turns out, the unix time is NOT junk in them. The short I identified is *before* it. Oops
The hexpat is also fixed up so it can analyze v3, v4, and v5 successfully.
As it turns out the thing I marked as "header size" is more likely just a discarded revision.
Anyways, to detail this: pak version 5 adds fields to the header for sector alignment. The reader now handles this and reads the sectoralignment TOC entry, which now allows STREAMS (and any other packages with this set?) to extract properly.
Woohoo.
Also fix some warnings and potential issues that building the entire EuropaTools codebase under those flags showed.
Later on once we drop the libpixel and stbiw dependencies, we can probably turn on -Werror for release builds.
