– Add loading of assets from the user directory
– Change most asset path defintions agnostic to the base path (“assets/textures” => “textures”)
– Load models using the FileReader
– Change the relevant path variables from char to wchar
Resolves #87
Hi! What looked like a pretty straight forward ticket kind of grew into something bigger, as is tradition around here it seems. I had initially planned to simply create a way to determine the user’s home path in a more or less sensible way, that quickly spun slightly out of control though.
The first thing I quickly realised is that I didn’t actually load all the assets using the FileReader, both the models (not the shaders though) and the Python scripts were loaded directly. Unfortunately, there was no obvious way to quickly get the Python scripts into the asset packages as well, it is definitely still planned though. On a happier note though, it did work just fine for the models after a bit of refactoring.
To spice things up a bit further, I also came to realise that the Windows Way of getting the right path by calling SHGetKnownFolderPath() returns wchar_t*, not just a plain old char*, which was a bit of a problem since the existing code definitely did not deal with that, so a fair amount of refactoring was required there. On the Linux side of things I did look at the XDG specifications .. and decided to ignore them and just go for getting the $HOME variable instead. For all intents and purposes that’s fine for the foreseeable future.
Last and certainly not least was the fact that all asset source definitions started with the magic word “assets”, which was actually a relative path definition from the olives executable itself. This makes perfect sense, up to the point when you want to actually dynamically want to piece together a “virtual” directory structure from different sources, which clearly do not start in a path named “assets” – probably not anyway.
This led to the quick decision to cut the “assets” out of all the definitions, meaning
"texture_file_path": "textures/wallpapers/wall_brick.png",
turned to
"texture_file_path": "wallpapers/wall_brick.png",
Finally all that worked, only for me to realise that the actual directory handling was not quite as dynamic as I thought, it just happened to work if the current relative “assets” path is being used, not a biggie, but still somewhat annoying for what seemed like a relatively self-contained task at first, so not exactly a wonderful example for best practices in software engineering.
Be that as it may, it’s done, it’s working, that’s good. 🙂 Next up will probably be listing the save games in the UI similar to the scenario selection, after that, who knows, maybe actually some code to safe the current state. Let’s see. Byeeee!