Merge ftldat.dll and itb_io.dll into a single .dll
#208
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is primarily motivated by itb-community/ftldat-rs#1, which (among other things) asked for
ftldat-rsto be published as a standalone package that other Rust projects could interact with.This represented an opportunity to reduce duplication in both
ftldat-rsanditb-ioprojects, since both of those projects had to include their own copies of files that allowed them to export Lua bindings.As a result, I created https://github.com/itb-community/itb-rs-lua, which includes
ftldat-rsas a dependency (crate), and fully incorporates https://github.com/itb-community/itb-io-rs, with an improved project structure that should be easier to extend in the future.Changes in file sizes:
While preparing
ftldat-rsfor publishing, I also overhauled the way it loads files. During reading, files are now memory-mapped, rather than read into a buffer. Also, the in-memory representation of the.datfile now only stores a list of entry headers, rather than their full contents, which dramatically reduces memory usage. In practice, there aren't any noticeable speed improvements, but ITB's memory usage no longer spikes into over 350MB range during startup.The fact that the archive file is now memory-mapped means that is important to properly destroy each
FtlDatinstance (by invokingFtlDat:destroy), as it actually holds system resources now.Since files cannot be overwritten while there exists a lock on them, we cannot overwrite
resources.datwhile anFtlDatinstance exists. To resolve this issue, when writing to a file,FtlDatinstances first write to a temporary file, release system resources, and then replace the destination file with the temporary file. This means that once theFtlDat:writemethod is invoked, that instance becomes invalid and cannot be used anymore.This also means that when there are multiple
FtlDatinstances created from the same source file at once, it is impossible to overwrite their source file. In practice, this shouldn't be an issue, as the mod loader is the only client ofFtlDat, and provides hooks that mods use to apply their desired changes.