Repository navigation
[Core] Library Integration & Some Changes #5
Description
Mcommon has turned out to be a bit of a.. not so great thing. It was originally brought in both cause of bigfile and me wanting C++20 features (while C++20 was still not standardized), however we actually don't need it anymore. (since C++20 is out!)
I propose:
- Removing mcommon (implementing some of the stuff using the standard) and moving to C++20.
Binary reading would be refactored greatly. - Refactoring code to not use the annoying uintXX typedefs and just use <cstdint> (which were themselves a carryover from another project.)
- Moving bigfile from its own dedicated repository into the SSXTools repository (for usage in SSXTools)
- (Maybe) Moving makecbxs into the SSXTools repository, and cleaning up the code (as it was very "5-second" even for me.)
- Renaming the project from EAGLe to SSXTools
In short, this issue tracks me basically turning SSXTools into a spot for all of the code I've written for modding SSX.
A good thing this offers is that in theory the SSXTools GUI could be given a lot more features than what it has.
The last proposal can be discussed here, as with all of them, as this is kind of a community RFC.
Activity
modeco80 commentedon Jul 17, 2021
2 and 1 have been partially done in the new dev commits
modeco80 commentedon Sep 22, 2021
A bit of a update (as SSXTools is actually something I'm working on again):
Mcommon removal is blocked by the fact that bigfile and Core.h are still submodules or still using mcommon.
Other than that, the Streams system is going to be adopted basically throughout, nuking reliance. Also, std::span is a thing now, so for anything taking a non owning buffer which needs to encode length, that will be used from now on.
I have decided that it's probably in the best to completely rewrite bigfile for inclusion, as a lot of code isn't all that great.
Lazy retrieval of file data will definitely be revisited, since core::uint24le/be is a thing, and I don't really know why I removed it in the first place.
Makecbxs is probably going to go the same route, as it's code is arguably even worse.