Tag: c++

– Add support for loading save games from the main menu
– Add support for loading save fames from within a running simulation
– Add support to the SnapShotManager to load save games
– Fix locking issues

Resolves #89, #88

Hello! This commit took quite some time as I was stuck with a weird UI synchronisation problem which turned out to be.. me missing a function call to synchronise things.
As I had encountered similar problems before (and fixed them) I was hunting for yet another bug, unfortunately in this case that was wrong in hindsight, I simply had to manually force-synchronise the UI state and all these warnings (and the occasional crash) went away.

On the happier side of things, it is now possible to load save game files from both the main menu and the in-game menu, albeit they have to be manually generated.

As you can see, visually there is not much of a difference to the scenario selection, but it is quite nice to see three out of the four options to be clickable now.

Next up will probably preliminary support for actually saving games, which will hopefully go quicker, it comes with a variety of sub-tasks. But it is certainly going to be a lot more motivating and exciting than drawn out bug hunting. 🙂 Byeee!

– 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!

Work around race conditions that may result in deadlocks on Windows

Hello! This does exactly what it says, hopefully without causing any further problems, but time will tell. I’m not quite sure what topic will get picked up next, but one of the best candidates is initial save game support. Let’s see. Byeee 🙂

– 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! 🙂

– 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. 🙂

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!

– 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 🙂

– Add basic scenario list to main menu (WiP)
– Make the scroll button ratio for the dynamic row container .. dynamic as well
– Fix container-in-container case in the dynamic row container
– Always re-calculate the visible child indices when clearing and adding child elements
– Enforce a 16:9 ratio to make UI elements draw more predictably

Relates to #86

Hi! It has been quite some time since the last commit/post, this is mostly due to two factors: I was quite a bit distracted in my free time and, as always, working on UI code tends to get somewhat messy.

While the first factor was definitely a big one, it was worth noting that I stumbled over quite a few issues, which can be seen by the sheer number of separate issues addressed in this commit. The biggest ones of these were definitely certain shortcomings in the DynamicRowContainer class, so far mostly used in the very specific use case in the main content area on the right hand side .

While that in itself is no problem, it also made me do some assumptions about how to scale some things – also it was not the most dynamic (there is a certain irony given the name of the class) use case. The biggest and by far most frustrating problem was the missing support for having containers as child elements in the dynamic containers.
This was no issue when a simple non-container element was used (like the buttons when buying an object), however when a container was used instead, the reported number of active widgets and the amount of model data did no longer match, as fetching the actual model data in fact did work as expected.

The fact that these two numbers much however is one of the assumptions made by the renderer to determine if it can already draw the UI or if it has to wait until the synchronisation from the main thread (which will modify the UI data) to the render thread (which takes the provided data and turns it into something that can be shown on screen using Vulkan) is done. In this case, the synchronisation was already done, it simply didn’t return all the element it should have, leaving the renderer to draw no UI.
To make this extra frustrating, while in menu mode, there is nothing but UI, leaving me with a blank black screen. The issue it self once identified was fixed withing minutes, tracking it down however lead me on a wild goose chase of dead ends. Oh well.

This very bare bones list is the result of all that, please also note that OLives now enforces a 16:9 screen ratio, as the number of UI issues arising from this being freely changeable were simply too many.

The selection is not done yet, I’m not quite sure how much information about each scenario to show here (besides simply the title, as it is the case now). It is also still very much work in progress as there are some remaining issues that need to be ironed out. Feels good to finally have something worth committing again.

So until next time, definitely not with such a big gap in between. Byeeee 🙂

– Add support for object-in-object logic in snapshots
– Fix visual glitch when deactivating light sources inside rooms
– Fix order in which to reset some data structures when starting the simulation
– Add support for setting the active state (of objects that are togglable)

Resolves #83, #84

Hello! This commit wraps up the snapshot format, at least for now, as the upcoming (TBD) saving mechanics may need some further work on it. However, I’m pretty pleased with how things turned out for the time being. For example take this screenshot of the current version of house1.json:

The astute observer will notice the two agents currently sitting on the couch (leveraging the object-in-object mechanics) as well as the lamp being in the inactive state. Both of which can be defines as follows now:

Unexpectedly there were also some issues which needed urgent fixes, that was luckily a lot easier than I had originally thought. One of them was introduced recently as part of the object support in the snapshot format, the other one was a bit more weird, as there were rather ugly artefacts when turning off a light source while it is inside a room. This bug had to have been around for quite some time, but apparently somehow went unnoticed.

Next up will be the ability to actually select the scenario from the menu. Byeee 🙂

– Make controllable object specific properties configurable
– Remove hardcoded agent creation/adapt scenario files to creat them instead

Relates to #83, #84

Hi! As hard as it is to believe and weirdly unceremoniously it finally happened:

The two agents are now finally generated by configuration, rather than by code:

Using it is pretty straightforward, a new “controllable_info” property was added to the existing object configuration which allows the user to configure all of these specific properties. All of these, except the name, are optional and will default to sensible values if left unconfigured.

That means the only task left about this is how to handle the object-in-object mechanics. I am still arguing with myself whether or not to postpone that until I actually implement the save function, as that feature realistically is not a must-have for defining game scenarios/maps and rather do something else instead. But let’s see, time will tell. Byeeee. 🙂