Closed Dawoodoz closed 4 years ago
The existing functionality has now been moved to the API folder with global functions in the dsr namespace.
Saving and loading of raw buffers are now implemented in a new file API. This API is then called in the implementations for loading and saving text, so that each part can be tested separatelly and joined with minimal implementation complexity.
Anyone wanting to define a binary file format can then encode and decode the content into buffers and use the file API to handle the messy file system.
It would probably also be convenient to load and save images using buffers, which should already be implemented in stb_image. Then the caller has more control over how resources are loaded by separating encoding from file access.
This would abstract away technical details of the implementation and allow easily saving, loading, compressing and packing binary files for when the assets start to grow. Having a procedural API also makes it easier to find and less likely to break backward compatibility after the first release. As a fundamental feature, this has to be well tested.
Without this abstraction of Buffer handles, adding new functionality like sub-buffers (reference counting internally while still having to solve issues with aliasing) will probably break a lot of backward compatibility. The goal is to have a more clear separation between version stable APIs and internal functionality that may change while the library gets more features.
With a clear separation between file access and format parsing, regression tests will be much more useful by focusing on many smaller problems. Storing a file's raw content in a buffer is used anyway as an optimization to prevent the worst case of spending minutes to save a small file when the system frees and replaces its buffer for each new character being added.