Re-implementing from old program
While it was totally unnecessary, I felt like re-implementing beta format 1, and because the internal NBT format is basically alpha format 2, I implemented that too. I had several reasons doing so, like supporting down to 1.0, check how much faster this version of PixelMap is compared to its previous version, and updating the versatility of the library itself, as I found parts of it being limited to the current save formats implementation. In the process I made some parts of the code a bit smarter and easier to use, while also reducing both memory footprint slightly and added more move semantics where needed.
Alpha format is very not optimized, and while most players will not play that, if not for nostalgia, it is good to provide a whole package, when it is rather easy to support it. Do note that the format is very different from the current format, but the biggest slowdown is not the conversion to the new format, but actually reading each individual file, as each file consist of one chunk only. But as said previously, it also made me look a bit more on the system and fix some places where I could either optimize or refactor so it makes more sense how things are made. It was quite a pleasant experience, except for the horrendous conversion.
|
|
The worst part is not that it looks ugly, but when I initially wrote this I found it difficult to deduplicate them into a single function. However, after some more tinkering I found a way.
|
|
And that reduce the previous blocks to the following, making it a lot easier to locate a bug of a specific problem instead having to separate it from duplicate code.
|
|
It is not perfect, but at least it is better managed. Splitting these into two functions, or refactoring it further may give even better result, but this is fine for now. My biggest concern right now is that while I am using STL containers, I do not use STL generics to generalize explain what my templated functions actually needs. It is a subject of its own, but it would allow me to remove the specific use of std::vector
(even if it is very efficient), to a more generalized format that allows any type of container that follows the specific requirements.