Commit 47d4288e

– Add windows support for asset packs
– Fix windows build

Resolves #95

Hi! This commit is mainly about fixing the Windows build again, that also means the CI pipeline is happy again. Unfortunately while testing in both Wine under Linux and natively on Windows (10) I noticed two out of the three existing scenarios seem to freeze OLIves up, something that does not happen running the native Linux build.

So before doing anything else, the next item on the agenda will be fixing that up I reckon. Byeeee! πŸ™‚

Commit d6bf630

– Move all file reading to the FileReader class, which was weirdly not doing that before
– Add support for loading assets from zip files
– Turn the FileReader into a singleton
– When initialising the FileReader scan all the files (and asset packages) and keep track from where to lead each fileΒ Β Β Β 

Relates to #95

Hello! This commit is quite a bit more elaborate than the last one. Ignoring the actual implementation details, this means that it is now possible to drop a “asset pack” (read: a ZIP file) into the assets directory. The contents of those will be scanned and made available transparently when using the FileReader class, every file path is considered unique, so whatever specific file path gets scanned first will be the source for it, with files on the actual file system taking precedence.
The asset packs are read in reversed alphanumeric search order, so the behaviour remains predictable. While I would like to take credit for this approach, I blatantly stole that idea one from the id Tech family of engines. πŸ™‚

In practical terms, should there be a specific texture with a path like assests/texture/blank.png (which there actually is) and it is loaded through the FileReader (as everything now is), the FileReader will transparently pick the correct source as described in the first paragraph, so all the configuration files remain forwards compatible to this.

As for the why of it, this is for scenarios which should be self-contained, meaning also contain their preview picture or any other assets they may require without polluting the actual assets directory. Furthermore this is also in preparation for save files, which once again should also definitely be self-contained .

All of this seems to work fine besides one minor detail, the Windows build. This should be no problem in itself really, however I could not be bothered yet to actually build libzip as well as its lovely dependency zlib on Windows yet. Furthermore, this broke the CI process, as it does not appreciate the failing Windows build. Not to fear though, fixing that is the next item on the never-ending to-do list. Byeeee. πŸ™‚

Commit 7f52d8c2

Turn the logger into a singleton

Hi! Unfortunately there is not that much to be said about this commit, as there should not be any functional difference. πŸ™‚ However, this is in preparation to a new feature in which I wanted to be able to have logging functionality without having to path the logger to yet another place. So nothing to exciting here, but hopefully I’ll have to report something more so soon, byeee!

Commit 01ecf0f2

– Flesh out the menu UI
– Fix usability problems

Resolves #86

Hello! While not taking quite as long as with the previous commit, once again I was somewhat held back by some rather frustrating bugs that popped up, as is tradition with any UI work I seem to be doing.
Be that as it may, this is the new game dialogue, at least for the time being. I am actually quite happy with it, even though I feel like I should probably add some more content there, I am not yet fully certain though what more information could be put there. Check out the current state below:

It’s a bit hard to say what exactly will be next, as I really haven’t made up my mind yet, but stay tuned and find out more here soon. Byeee πŸ™‚